Messaging & SMSC (SS-18) — Brivas capability

Messaging & SMSC — the depth.

The messaging core: an SMSC with routing rules, a protocol split across SMPP / HTTP / SS7, message splitting for long content, DLR correlation and a retry ladder — under one governed send plane. Every send is consent-, quiet-hours- and suppression-checked before it leaves, with a critical OTP/paging lane exempt from quiet hours; refusals are governance (HTTP 200 with an explicit status/reason), never silent drops. OTT — WhatsApp, Messenger, Viber, Google RCS, Telegram — rides the same pipeline with per-tenant channel capabilities, in-session vs out-of-session accounting, template gating and normalized delivery receipts.

Every capability maps to a real method + path.

SMSC routing rules & protocol split

Route messages by rule, split long messages into segments, choose the bearer protocol (SMPP / HTTP / SS7) and submit to the SMSC — the wholesale messaging switch under the friendly send API.

GET/api/v1/smsc/rules
POST/api/v1/smsc/rules
POST/api/v1/smsc/route
POST/api/v1/smsc/split
POST/api/v1/smsc/submit

DLR correlation & retry ladder

Delivery receipts are correlated back to the source message; a configurable retry policy drives the retry ladder, and due retries are drained on a schedule.

POST/api/v1/smsc/dlr
GET/api/v1/smsc/dlr/{id}
POST/api/v1/smsc/retries/due
GET/api/v1/smsc/retry-policy
POST/api/v1/smsc/retry-policy

Governed send plane — consent, templates, receipts

Typed intents and a plain send, gated by recorded consent, suppression lists, quiet hours and unsubscribe, with versioned templates and critical-sender registration for the OTP lane. Messages expose receipts, failover and polling.

POST/api/v1/send
POST/api/v1/intents
POST/api/v1/templates
POST/api/v1/consent
POST/api/v1/critical-senders
POST/api/v1/suppressions
POST/api/v1/unsubscribe
GET/api/v1/messages
GET/api/v1/messages/{id}
POST/api/v1/messages/{id}/failover
POST/api/v1/messages/{id}/receipt

OTT channels & session windows

Register per-tenant OTT channels, send and receive on them, manage approved templates for out-of-session sends, and read the live session window — the in-session vs out-of-session distinction is enforced at send time.

GET/api/v1/ott/channels
POST/api/v1/ott/channels
POST/api/v1/ott/send
POST/api/v1/ott/inbound
POST/api/v1/ott/templates
POST/api/v1/ott/templates/{name}/approve
GET/api/v1/ott/window

A governed WhatsApp send with failover to SMS

A transactional order update, template-gated on WhatsApp, correlated to a receipt, failing over to SMS.

1TemplatePOST/api/v1/templatesRegister a versioned transactional template; out-of-session OTT sends require it.

2WindowGET/api/v1/ott/windowCheck the recipient's WhatsApp care window: in-session or out-of-session?

3SendPOST/api/v1/intentsSend the typed intent; consent + quiet-hours checked, template applied if out-of-session.

4ReceiptGET/api/v1/messages/{id}The normalized receipt rides the timeline: queued → sent → delivered → read.

5FailoverPOST/api/v1/messages/{id}/failoverIf WhatsApp doesn't land, the ladder steps to SMS over the SMSC.

Where it sits in the platform.

SS-18 is the first-party messaging rail. It authenticates with SS-01, meters to SS-60/SS-10, and hands A2P traffic to SS-38 VoxGuard for fraud screening on the same plane. Consent changes and sends are audit-chained (ADR-0014); recipient PII is masked in logs.

Depends on

SS-01 identitySS-38 VoxGuard (A2P screen)

Feeds

SS-36 mediation (usage)SS-10 chargingSS-41 A2P / DLR