message.sent
Fired when the message has been accepted by the upstream provider. Includes provider-side message ID and any returned status.
Partners and integrators use the same REST surface that powers the admin UI. Authentication is via partner-scoped access keys (live or sandbox); rate limits are configured per partner; responses include idempotency-aware identifiers so retries are safe.
Send messages on any channel, manage contacts, fetch conversation history, check account balance, list gateways, retrieve usage statistics. Every mutating call accepts an idempotency_key header to deduplicate retries.
# Send a WhatsApp template message POST /api/v1/messages Authorization: Bearer ak_live_•••••••••••• Content-Type: application/json Idempotency-Key: 7f3e2c1a-9b8d-4f6e-a2c1-b3d4e5f6a7b8 { "channel": "whatsapp", "to": "+15551234567", "template": "order_confirmation", "language": "en", "variables": { "name": "Nayeem", "order_id": "TR-204821", "eta": "15 minutes" } } # 202 Accepted { "id": "msg_01HNQX2P8Y9R3T4V5W6Z7A8B9C", "status": "queued", "channel": "whatsapp", "cost_estimate": "0.012", "created_at": "2026-05-23T14:22:17Z" }
Outbound webhook delivery for message lifecycle events. Platform-side delivery in production; partner-side webhook configuration on the immediate roadmap.
Fired when the message has been accepted by the upstream provider. Includes provider-side message ID and any returned status.
Fired when the provider confirms delivery to the recipient device. Not all channels support this — Email and SMS yes, broadcast channels no.
Fired after exhausting retries. Includes the last error, the retry count, and the refund posted to the wallet.
Email-specific. Permanent bounce includes diagnostic info; transient bounces feed into the retry budget instead.
Fired when an agent is assigned to a conversation. Useful for downstream CRM enrichment or routing dashboards.
Fired when an inbound message resolves to an existing contact via external-ID matching. Useful for triggering downstream personalization.
Whether you're integrating an external system, building a native mobile app, or driving the admin UI itself — every call goes through the same auth, rate limit, and audit pipeline.
What partners and integrators build against. Live and sandbox key prefixes (ak_live_ and ak_test_) keep production data safe from integration experiments. Per-partner rate limits, idempotency-aware identifiers, and structured error responses.
Token-based auth, FCM push token registration, conversation polling, message send. Designed to back native iOS and Android admin apps once they ship. API ready today; client to build.
Used by the admin UI for synchronous send-and-confirm flows. Same idempotency, same rate limits, same auditing — admin actions are equally accountable to the audit log as external API calls.
Every partner has a parallel sandbox environment with isolated access keys (prefix ak_test_) so integrations can be built and tested without affecting live customers or incurring real-world send costs.
Sandbox contacts, conversations, and wallets are completely separate from production. Sandbox messages never leave the platform.
Sandbox responses match production exactly — status codes, error envelopes, webhook payloads. What works in sandbox works in production on day one.
Every page is server-rendered semantic HTML — no JavaScript hydration required. A maintained sitemap.xml and robots.txt give search engines and AI tools (ChatGPT, Gemini, Claude, Perplexity) clear indexing rules. URLs are clean and extensionless via .htaccess rewriting; canonical tags prevent duplicate indexing across sandbox and production domains.
Request an evaluation and you get a sandbox API key, a provisioned tenant, and a technical contact on a private Slack channel — usually within one business day of the intake call.