Overview
Inklura's marketing and support features are delivered by a handful of PRISM tool apps (SMS Designer, Mail Designer, SEO, the console) sitting on top of two distinct backends. Knowing which backend a feature uses tells you how to call it, where its data lives, and — importantly — what is programmatic versus what is manual or still stubbed.
Two worlds
Every integration on this page talks to one, or both, of these:
| Backend | Where | What it is | Typical use |
|---|---|---|---|
| bext loopback SDK | http://127.0.0.1/__bext/sdk/* |
Per-app KV, queue, and a warm task-executor, reachable only from on-host callers. | A tool app's own storage and background work — SMS campaign records, SEO report jobs. |
| company-manager tRPC | https://manage.inklura.fr/api/trpc/* |
The canonical Platform API over Neon Postgres. | Email campaign CRUD/send, campaign analytics, journeys, helpdesk. |
The SDK is on-host only — a PRISM site reaches it over loopback with an
X-Bext-App-Id header, and each app's data is scoped to that id. See the
SDK Overview, KV, Queue, and
Tasks pages. The tRPC API is the public surface documented under
Platform API; its calling conventions (superjson envelopes,
result.data.json, Bearer auth) apply to every tRPC procedure named here.
The integration surfaces
| Surface | Backend(s) | Primary entry point |
|---|---|---|
| SMS campaigns | bext SDK (KV) + Capitole Mobile gateway | POST /api/campaigns (SMS Designer) |
| Email & MJML | company-manager tRPC + Mautic bridge | campaigns / emailAnalytics routers |
| Marketing journeys | company-manager tRPC | journeys router |
| SEO reports | bext SDK (KV + tasks) + provider APIs | POST /api/seo/reports (SEO app) |
| Helpdesk & KB | company-manager tRPC | helpdeskKb router + /manage/helpdesk |
Honesty: what is programmatic vs manual or stubbed
Several of these features are partial. Read these before you build against them:
SMS delivery percentage is human-entered, not fetched. The Capitole gateway has no delivery-receipt (DLR) callback wired up. On reports, "Delivered" and "Read" are benchmark estimates (~95%) unless an operator manually types in the figure from the Capitole portal. Click metrics are real. See SMS Campaigns.
Journey action steps are mostly v1 stubs. In a journey, only the EMAIL
step actually sends. SMS is a non-functional stub, and WEBHOOK,
UPDATE_FIELD, ADD_TO_SEGMENT / REMOVE_FROM_SEGMENT, CREATE_TASK, and
SEND_NOTIFICATION are advance-only no-ops today — a WEBHOOK step does not
emit an outbound webhook. See Marketing Journeys.
SMS scheduling is delegated, not local. There is no local cron or queue for
SMS sends; a scheduled campaign is handed to Capitole's prog field and the
gateway holds it. Email delivery is delegated to a self-hosted Mautic bridge.
Email analytics degrade gracefully when the external analytics service
(QUEUE_MANAGER_URL) is unreachable.
Where to next
| Page | What it covers |
|---|---|
| SMS Campaigns | The Capitole gateway, the /api/campaigns action API, KV storage, delivery-% honesty flag, public reports |
| Email & MJML | The MJML composer, the Mautic delivery bridge, campaigns CRUD/send, emailAnalytics, open/click tracking |
| Marketing Journeys | The journeys router, triggers, step types (with the v1 stub flags), templates, and how enrollment fires |
| SEO Reports | Data providers, the async report pipeline (POST /api/seo/reports + SSE), and the warm task-worker |
| Helpdesk & Knowledge Base | The helpdeskKb router, tickets as inbox threads, and the KB as a defineEntity example |