> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# API recipes hub: pick the recipe by flow shape

> Landing for the api-recipes folder — triages the four sub-cookbooks (operations, contact lifecycle, US 10DLC pre-send chain, third-party migrators) by the flow chain you need to build, then points at the root cookbooks for core messages/verify/voice, the per-language long-form page, and the channel-fallback and idempotency recipes.

# API recipes hub

The folder behind [REST API recipes](/guides/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](/sdks/index) or a coworker's bookmark, the fastest mental model is: **core sends and pillar loops = [REST API recipes](/guides/api-recipes)** (35 numbered tasks), **which language? = [Per-language recipes](/guides/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

| Cookbook | Use it when your chain is… | The loops inside |
| - | - | - |
| [Operations endpoints](/guides/api-recipes/operations) | approvals queues, cascade/route preview before smart-send, the message-history search DSL, the SMPP no-receipt window, brand-identity trust, gating a send on a risk score | second-officer approver round trip, `cascade_policy` arming, Bash-level search, `smpp.fallback` receipts, trust read, `risk/score` gate |
| [Contact lifecycle](/guides/api-recipes/contacts-lifecycle) | opt-outs, segments + frequency caps, or a day's usage into metering | bulk suppress → export → per-channel re-opt-in, AI segment autopilot → lookalike materialization, frequency-cap rules read/write, daily usage pull |
| [US 10DLC pre-send chain](/guides/api-recipes/us-10dlc-posture) | any US SMS marketing send — the four gates you must pass before `POST /messages` | 10DLC registration-state read, brand + campaign filing over the API, quiet-hours and consent pre-check, marketing-vs-transactional lane tagging |
| [Third-party migrators](/guides/api-recipes/third-party-migrators) | a provider cutover (Twilio, Sinch, MessageBird, Vonage, Infobip) — the five provider-specific per-source guides hang off the same five loops | Messaging-Service-SID → `messaging_service_id`, number port LoA URL, status-callback rewire to `message.delivered`, TwiML → published IVR flow, verify-codes swap; includes the 429/422 branches a cutover script hits |

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](/guides/compliance-privacy-register) use.

## By flow shape

| I need to… | Start here |
| - | - |
| Send a message and track it through poll + webhook | [REST API recipes](/guides/api-recipes) — tasks 1–2 |
| Batch-send with an idempotent 429 backoff loop | [Per-language recipes](/guides/per-language-recipes) — §2 |
| Run an OTP send/check round trip | [Per-language recipes](/guides/per-language-recipes) — §3, or the dedicated [verify in 30 min](/guides/verify-in-30-min) path |
| Build a two- or three-hop channel-fallback chain (WhatsApp→SMS, email→SMS, voice→SMS) | [Channel fallback recipe](/guides/fallback-channels-recipe) |
| Wire the retry and idempotency contract on every non-GET | [Idempotent requests](/guides/idempotent-requests) and the [error-handling runbook](/guides/error-handling-runbook) |
| Cut over from a provider (Twilio, Sinch, MessageBird, Vonage, Infobip) | [Third-party migrators](/guides/api-recipes/third-party-migrators) |
| Run a US SMS marketing send without hitting the 10DLC gates at send time | [US 10DLC pre-send chain](/guides/api-recipes/us-10dlc-posture) |
| Drive an operator-side approvals queue or the message-history DSL | [Operations endpoints](/guides/api-recipes/operations) |

## 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](/guides/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](/sdks/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](/guides/per-language-recipes) §1 has each language's ingest loop; [REST API recipes](/guides/api-recipes) tasks 1–2 stay on Node.
* **Voice + recordings** — place the outbound call, read its status and recording leg. [REST API recipes](/guides/api-recipes) task 11 chains `POST /voice/calls`, `GET /voice/calls/:id`, and the voice webhook; the [Voice fallbacks](/guides/fallback-channels-recipe) end of the fallback page adds the voice→SMS branch.
* **Verify + history** — OTP send and check, then the message-history DSL. [Per-language recipes](/guides/per-language-recipes) §3 covers the send/check round trip per language; [Operations endpoints](/guides/api-recipes/operations) recipe 3 carries the history DSL once the verify flow writes rows.

## Sibling recipe pages this folder doesn't absorb

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

## See also

* [SDK index](/sdks/index) — which SDK is published where, and the escape-hatch map per language.
* [API integration primer](/guides/api-integration) — auth, base URL, sandbox test keys.
* [Verify fallback chains](/guides/verify-fallback-chains) — the OTP step-up chain a per-message `cascade_policy` does not replace.
* [Compliance privacy register](/guides/compliance-privacy-register) — the consent and erasure concepts behind the contact-lifecycle recipes.
* [US 10DLC posture concept](/guides/10dlc-marketing-baseline) — what the pre-send chain on the sibling page enforces.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.