Programmable Messaging API  ·  View 15 of 22  ·  Runtime

Per-Channel Pipelines

Five lanes behind one internal contract, and the stage where they genuinely differ.

Editable source SVG draw.io All views
Resolve Adapt Pace Submit Receipt Settle SMS via SMPP Number type and MCC GSM-7 or UCS-2 split Bind window lease submit_sm per segment deliver_sm DLR Rate per segment SMS via aggregator Same resolution Provider JSON shape HTTP route lease POST, provider id Webhook receipt Rate per segment WhatsApp Business identity check Approved template only Per-number tier limit Graph send Read and delivered Conversation pricing RCS Capability probe Rich card or fall back Hub window lease Agent message Event, often absent Fallback hop rated too Inbound (reverse) Verify and dedup Normalise to one shape Per-route rate limit Keyword interception Consent written first Tenant webhook, actioned Per-Channel Pipelines Behind One Internal Contract Adding a channel adds a lane. Nothing in the ledger or the state model changes. v 1.0 · owner Integration Platform Architecture

Decisions

  • The lanes share Resolve, Pace and Settle and diverge only at Adapt, Submit and Receipt — that split is the adapter boundary made visible.
  • RCS is drawn with an explicit capability probe and a fallback, because a rich message that cannot be rendered is a different message with a different price.
  • The inbound lane runs the same stages in reverse and writes consent before the tenant is notified.

Assumptions

  • Nine channels at full scope; the MVP ships one and the adapter contract is proven by the second.
  • WhatsApp conversation pricing and SMS segment pricing are both expressed as rated usage per attempt.

Risks

  • RCS receipts are frequently absent, which inflates the unknown rate for reasons that are not the platform's fault and will be read as if they were.