Kirada, Djib Payroll and SMKit never hold a Meta token or a Stripe key. They send one signed request to this service, and it handles the providers, the retries, the idempotency and the audit trail on their behalf.
Every external call is queued, bounded and idempotent.
Provider complexity, credentials, retries and audit history stay here. Each product keeps a single contract and clear ownership of the events it cares about.
Each product gets its own request and event secrets. Requests are timestamped, signed over the raw body, and replay-protected by a persisted single-use nonce.
A provider-neutral contract routes traffic through the Meta Cloud API, with a second provider kept behind a hard-disabled flag so a stale column can never silently reroute production traffic.
Checkout sessions, portal sessions, customer mapping and the full Stripe webhook lifecycle are coordinated once, then fanned out to whichever product owns the customer.
Status changes become durable event rows with stable IDs before anything is sent. Delivery is queued, signed, retried on transient failures, and recorded either way.
Phone numbers, display names and message bodies are encrypted at rest. Lookups run against deterministic SHA-256 hashes, so no plaintext identifier is ever indexed.
Queues, exceptions, slow requests and failed deliveries surface in one secured console. It is deliberately read-only — every mutation is an audited console command instead.
Traffic crosses a boundary in three directions. All three verify the exact raw body with the same canonical string, so there is one rule to reason about instead of three.
METHOD PATH TIMESTAMP REQUEST_ID SHA256(raw body)
Meta and Stripe webhooks are verified against their own signature schemes, persisted as durable event rows, then queued. The HTTP 200 goes back before any domain work runs, so a slow processor never causes a provider retry storm.
Every /api/v1 route sits behind one middleware that checks the signature, that the application is enabled, that the timestamp is fresh, that the request ID has never been used, and that the caller is inside its rate limit.
Outbound events are signed with a separate event secret and posted to the product's webhook. A 200 or 202 marks it delivered; a 5xx or 429 is thrown back onto the queue; anything else is recorded as a permanent failure with its status.
Read live from GET /health/ready, which verifies the database, cache, queue connection and the configured WhatsApp provider on every call.
Adding a product is a configuration exercise, not another provider integration project. Read the integration contract, or see how the whole thing is put together.
