Skip to main content

​
Inbound event catalog

Inbound message statuses (delivered, failed, read, received, opt-out) come from every carrier Orbit integrates — Telnyx, the Devotel softswitch, DIDWW, and Meta — and each carrier reports its own status strings. Orbit folds all of them onto the same canonical webhook events. The Inbound event catalog is the dashboard view of that folding: one row per canonical event, listing every raw upstream status that arrives as it. Use it before you write a receiver branch — the catalog answers “which canonical event do I subscribe to, and which raw provider statuses will arrive as it?”

​
Open the catalog

In the dashboard, go to Developer → Webhooks → Inbound event catalog (/developer/webhooks/inbound-catalog). The page is available to members with the owner, admin, or developer role. The catalog is static platform metadata with no tenant data, so every member with one of those roles sees the same table.

​
The catalog endpoint

The same table is served machine-readably:
GET /api/v1/webhooks/inbound-events
The response lists one entry per canonical event a receiver can observe, each with the canonical status, the high-level kind, and the full list of upstream carrier statuses (grouped by carrier) that normalize to it. See Normalized inbound event envelope for the response shape.

​
Read an entry

The page has two panes: a searchable list of canonical events on the left, and the selected event’s detail on the right. Each entry shows: The list’s search matches canonical event names, statuses, kinds, and provider vocabularies, so typing delivrd finds the same entry as typing delivered.

​
Put it to work

Use the catalog when your handler sees a raw status that does not match any branch:
  1. Search the raw status (for example UNDLV) in the catalog.
  2. Read off the canonical event it resolves to (for example message.failed) and the canonical data.status (for example failed).
  3. Check that your handler’s switch covers that canonical event — SMPP UNDLV-style codes, Telnyx failure strings, and DIDWW statuses can all fold into the same event.
The same table ships in the SDK as normalizeInboundEvent: pass it a raw carrier status (with or without the carrier name) and it returns the canonical event and status pair, so receiver-side validation never drifts from the platform’s mapping. One subscription can skip the enumeration entirely: set an endpoint’s events to normalized.inbound and it receives the whole inbound family (message.received, message.delivered, message.failed, message.read, and contact.opted_out). See Normalized inbound event envelope.

​
When you want the schema instead

The Inbound event catalog answers “which raw status arrives under which event” — a status-folding view. For the full schema of what an endpoint can subscribe to (every event type, with sample payloads and failure payload shapes), use the schema-level Event catalog at Developer → Webhooks → Event catalog (/developer/webhooks/event-catalog).

​
See also