Programmable Messaging API  ·  View 09 of 22  ·  Structure

Interface Catalogue

Four contracts in, four out, and the two that somebody else authenticates.

Editable source SVG draw.io All views
Inbound to the platform Send API REST, message or batch Status API id or client reference Carrier receipt endpoint signed or allowlisted Carrier inbound endpoint ack under 250 ms Programmable Messaging Platform Message spine admit, own, schedule, attempt Channel adapters one internal contract Outbound from the platform SMPP binds MNOs, static egress Aggregator HTTP REST per provider Rich channel APIs WhatsApp, RCS Tenant callback signed, retried, DLQ submit pull receipts inbound submit_sm submit send status Interface Catalogue — What Comes In, What Goes Out Interface / broker Application we own External / third party synchronous Four inbound contracts, four outbound. Omitted for legibility: the registry API (view 18) and the rated-usage stream (views 10 and 14). v 1.0 · owner Integration Platform Architecture

Decisions

  • The two carrier-facing inbound endpoints are treated as public and hostile: verified by signature where offered, by source allowlist plus a per-route secret where not.
  • Every outbound channel sits behind one internal adapter contract, so a new channel is an adapter and a route family rather than a change to the spine.
  • Tenant callbacks are at-least-once with a dead-letter path, and pull is the fallback of record.

Assumptions

  • Inbound acknowledgement to the carrier p99 ≤ 250 ms, inside every integrated carrier's delivery timeout.
  • Perhaps a fifth of the catalogue can push; the rest is polled or webhook-driven per provider.

Accepted warning

  • The route checker reports one clutter warning on this view: the "send" label lies across the tenant-callback line. Eight interfaces were tried and produce four such warnings; four interfaces produce one. The two omitted interfaces are named in the diagram note and drawn in views 10, 14 and 18.