Skip to main content

​
API recipes hub

The folder behind REST API recipes holds the four deep cookbooks the root page’s arrays won’t fit: operations, contact lifecycle, US 10DLC pre-send chain, and third-party migrators. This landing is the index that routes you to the right one by the chain you’re building, then closes with the sibling recipe pages and languages the root pointer page doesn’t cover. If you’re landing here from the SDK index or a coworker’s bookmark, the fastest mental model is: core sends and pillar loops = REST API recipes (35 numbered tasks), which language? = Per-language recipes (cURL + Python / Go / Ruby / PHP / Java / C# on each of message+DLR, batch, OTP, usage), the four deep sub-cookbooks = this folder, and the operational knobs those skip = the named recipe pages at the bottom.

​
The four sub-cookbooks in this folder

Every sub-cookbook states the tenant-owned control it drives. The 10DLC page and the migrators template lead with a note that the surface is tenant-owned — Orbit enforces the gate, your organization files the registrations, names the source resources, and makes the go-live call. That phrasing is deliberate: it’s the same boundary the compliance concept pages use.

​
By flow shape

​
Per-language scope

The root cookbook pairs every task with curl plus one typed SDK tab — Node for tasks 1–10, Python for 11–18, escape-hatch tabs on the rest. If your integration is not Node or Python, the Per-language recipes page re-runs the four canonical server loops — message + DLR webhook ingest, batch with pinned Idempotency-Key, the OTP round trip, and the paginated usage read — in cURL, Python, Go, Ruby, PHP, Java, and C#, and points at the right escape hatch (client.request, client.Request, $client->request, client.RequestAsync) where there is no typed helper yet. For the browser and mobile SDKs the second half of that page handles push tokens, in-app chat, and slot personalization. The SDK index remains the authority on which SDK is published where; this hub and the per-language page only sequence the recipes.

​
Runnable end-to-end flows

Three cookbooks are full start-to-finish integrations (not one endpoint); pick the one matching your destination surface:
  • Messages + status (and DLR webhook) — send, poll GET /messages/:id, and consume the signed message.delivered / message.failed webhook. Per-language recipes §1 has each language’s ingest loop; REST API recipes tasks 1–2 stay on Node.
  • Voice + recordings — place the outbound call, read its status and recording leg. REST API recipes task 11 chains POST /voice/calls, GET /voice/calls/:id, and the voice webhook; the Voice fallbacks end of the fallback page adds the voice→SMS branch.
  • Verify + history — OTP send and check, then the message-history DSL. Per-language recipes §3 covers the send/check round trip per language; Operations endpoints recipe 3 carries the history DSL once the verify flow writes rows.

​
Sibling recipe pages this folder doesn’t absorb

  • REST API recipes — the 35 numbered task-by-task cookbook at the root; this folder extends it, not replaces it.
  • API recipes meta — the editorial split: when a sample belongs on this cookbook versus on the per-endpoint overlay block.
  • Per-language recipes — cURL + six-language tabs on the four canonical server loops, plus the client-side loops.
  • Channel fallback recipe — two- and three-step fallback chains, sandbox magic-number validation, cascade-receipt reading.
  • Idempotent requests — the retry + Idempotency-Key contract every non-GET respects.
  • Error-handling runbook — the retriable vs terminal table every recipe here branches on.

​
See also