Overview

Inklura has three distinct mechanisms for recurring and asynchronous work. They live at different layers of the platform and are reached in different ways. Pick the one that matches where your code runs.

There is no generic outbound-webhook subscription system for third parties — you cannot register a URL and have Inklura POST your service when "something happens." See Outbound for what does and does not exist.

The three mechanisms

Mechanism Where it runs Reached via Use it for
bext loopback SDK (scheduler / queue / tasks) Inside a PRISM app http://127.0.0.1/__bext/sdk/* + X-Bext-App-Id header Cron jobs and background/retryable work owned by your app
company-manager BullMQ queues Inside the Next.js backend QUEUE_REGISTRY (internal) Platform-internal fan-out (email, SEO, social, commerce sync, workflow automation)
Inbound provider webhooks Platform receivers https://manage.inklura.fr/api/webhooks/* Receiving events from Stripe, WordPress, email/commerce providers

1. bext loopback SDK

The PRISM-app pattern. Every app reaches the SDK over trusted loopback at http://127.0.0.1/__bext/sdk/*, authenticated by the X-Bext-App-Id header (see SDK Overview). Three surfaces cover recurring work:

  • Scheduler — cron-style registration that POSTs your handler URL on a cadence. See Scheduled Jobs.
  • Queue — an at-least-once push queue with push-workers, retries, and a dead-letter. See Queue Workers and SDK → Queue.
  • Tasks — a warm task-executor for long-running jobs. See SDK → Tasks.
Tip

For anything recurring inside a PRISM app, prefer the bext scheduler/queue over system cron. See Scheduled Jobs → Prefer over system cron.

2. company-manager BullMQ queues

Inside the company-manager Next.js backend, a QUEUE_REGISTRY declares a set of BullMQ (Redis-backed) queues. These are platform-internal — you don't enqueue onto them from a PRISM app; the backend's own routers and webhook receivers do. Declared queues include:

  • webhook, webhook-retry
  • email-*
  • seo-*, social-*
  • woocommerce, prestashop
  • workflow-automation queues: workflow-execution, workflow-node, workflow-scheduled, workflow-webhook

Inbound provider webhooks (mechanism 3) verify their signature and then enqueue onto the webhook queue. A separate standalone tracking/analytics HTTP service runs at QUEUE_MANAGER_URL (default http://localhost:8085, internal only).

3. Inbound provider webhooks

Real HTTP receivers under https://manage.inklura.fr/api/webhooks/* for Stripe, WordPress, email providers, commerce platforms, delivery, and social. Each verifies a provider signature/secret and then enqueues the event. See Inbound Webhooks for the full catalog.

Which one do I want?

Goal Use
Run something on a schedule (daily report, watchdog, billing tick) Scheduled Jobs
Do retryable background work with fan-out and a dead-letter Queue Workers
Run a long job past the render deadline SDK → Tasks
Receive an event from Stripe / WordPress / an email provider Inbound Webhooks
Have Inklura call your external system when something happens Not a self-serve feature — see Outbound

Sub-pages

Page What it covers
Scheduled Jobs The bext scheduler: register / list / cancel, cron, shared-secret auth
Queue Workers Push-worker registration, the handler contract, dead-letter, durable job records
Inbound Webhooks The receiver catalog per provider, verify→enqueue, and the honest outbound story