Skip to main content

​
CDP destinations: outbound subscriptions and the circuit breaker

The Integrations → CDP page carries two event-flow directions. The source and destinations console guide walks both halves together; this guide is the destinations-only deep dive for the team that owns outbound delivery health — destination kinds, per-subscription state, the circuit breaker, the reset CTA, and the recovery workflow after an outage. If you run outbound forwarding as a distinct responsibility from ingest (the usual split — developers own the inbound secret, platform/admins own the destinations), this page is the reference for the outbound half.

​
1. What destinations are

A destination is an outbound subscription registered on the Destinations (outbound) tab of Integrations → CDP. Each row binds three things:
  • A receiver kind — where delivery exits. The named catalog covers Segment, RudderStack, mParticle, Hightouch, Marketo, Google Analytics 4, and Amplitude, plus a set of CRM/marketing platforms (HubSpot, Salesforce, Braze, Iterable, Customer.io, Klaviyo, and more) that connect through an OAuth flow. A Generic webhook kind points at any HTTPS receiver you control.
  • A target URL — for the direct HTTPS kinds. Every Orbit event the subscription matches is posted to this endpoint, signed with the destination’s own secret. OAuth-connected platforms resolve their target inside the integration flow, so no URL is held on the subscription row.
  • An event filter — the fixed catalog of Orbit event types (contact.created, message.delivered, conversation.started, agent.handoff_occurred, …) the subscription forwards, or Subscribe to all for a full-firehose feed.
Destinations are how Orbit’s events leave the workspace toward your downstream CDP, marketing platform, or warehouse webhook. They are the complement of the inbound Source half of the same page, which mints the secret your apps sign events with on the way in.

​
2. Per-destination contract: badge + reset CTA

Every row in the destinations table carries a live status badge and, when the delivery circuit trips, a manual reset action. The four states: The page header aggregates the tripped rows into a “N circuit-open — auto-reopens on first 2xx” count so a stalled destination is visible without opening the tab. The breaker closes itself: the first successful (2xx) delivery flips the row back to Active with no operator action. The Reset button on a circuit-open row is the manual branch — it hand-closes the circuit immediately after you’ve fixed the receiver, instead of waiting for the next live event to prove recovery. Behind the badge, each destination row also exposes a Last activity timestamp (the latest success inline; the latest failure while the circuit is open), a per-subscription Retry / replay-failed recovery path against the delivery log, and a Send test event action for pre-go-live verification.

​
3. Walkthrough: connect a destination end to end

​
Worked example A: a generic webhook receiver

The webhook kind is the general case — anything HTTPS that verifies signatures.
  1. Stand up your receiver endpoint. It must accept POSTs over HTTPS and verify X-Orbit-CDP-Signature (recompute the HMAC over <timestamp>.<nonce>.<raw body> with the destination secret, reject mismatches before processing). The same scheme the ingest-signing guide covers applies on the outbound side, so one HMAC helper covers both directions.
  2. On Integrations → CDP → Destinations (outbound), click Add destination. Choose Generic webhook, name it (e.g. Warehouse webhook), paste the receiver URL, and pick Subscribe to all or narrow the event filter now.
  3. The dialog reveals the destination’s signing secret once. Copy it into your receiver’s verifier configuration — it isn’t retrievable again.
  4. Click Send test event on the new row. The dispatch is synchronous and signed: the receiver should log a verified delivery, and the row’s badge flips to Active. A non-2xx answer here is the cheapest signal that the URL or verifier is wrong, before any live traffic is at stake.
That’s the full happy path. Live events now fan out to the receiver, each one recorded in the delivery log.

​
Worked example B: a vendor destination (Segment)

The named-kind vendors follow the same contract with a vendor endpoint as the target:
  1. Add destination → choose Segment (or RudderStack / mParticle / Hightouch). Name it (Segment production), and point the target URL at your Segment-side intake endpoint.
  2. Pick the event catalog entries your downstream pipeline expects (narrow the filter now — it is cheap to widen later, expensive to backfill noise).
  3. Copy the revealed signing secret into your Segment-side verifier (or the shim you run in front of Segment).
  4. Send test event and confirm the row flips to Active with a fresh Last activity timestamp.
For the OAuth-connected platforms (HubSpot, Salesforce, Braze, Iterable, Customer.io, Klaviyo, and the rest of the connected-platforms grid), the URL-and-secret part is replaced by the integration’s own OAuth connect flow — the row activates once that flow completes, and the Send test event action is intentionally unavailable (those destinations verify through the integration’s settings page, not a signed ping).

​
The circuit-open error branch

When deliveries start failing — non-2xx responses, timeouts, connection or TLS errors — the automatic retry path runs first. After five consecutive failures the breaker trips:
  1. The row’s badge flips to Circuit open and the destination stops receiving new dispatches.
  2. Failed deliveries accumulate in the DLQ, grouped by destination, with the HTTP status or transport error per row.
  3. Fix the receiver (restore the endpoint, correct the URL, update the verifier).
  4. Either wait for the next live event’s success to auto-close the circuit, or click Reset on the row to close it immediately.
  5. Drain the failure backlog with the destination group header’s Replay failed action (up to 50 recent failures per run), so nothing that queue-built during the outage is lost.
The reset CTA and the DLQ replay are the two halves of the recovery: reset re-opens the gate, replay re-drives what failed behind it.

​
4. How destinations relate to the schema and tracking-plan subpages

Destinations subscribe to the event stream the inbound half accepts; the two governance subpages shape that stream before it fans out:
  • The Tracking plan page declares which event types your workspace expects and what shape their properties take; violations warn in soft mode and reject in strict mode. A destination subscribing to contact.* only sees contact.* events, but it sees them whether the plan enforced them or not — the plan governs what ingest accepts, the subscription filter governs what the destination receives. See the tracking-plan guide.
  • The Event schemas page attaches a per-event JSON Schema with a drop / warn / ignore policy, so malformed payloads are handled at ingest rather than delivered downstream. Destinations are downstream of that decision — a schema set to drop removes invalid events before any destination dispatch runs.
Both subpages open from the tiles at the top of the Integrations → CDP page; the destinations table renders below them on the same page.

​
5. Data contract with the CDP module

The Integrations → CDP page is the operator-facing surface of the tenant’s CDP module. Two halves, one contract:
  • Source (inbound) rows expose non-sensitive ingest-secret metadata only — prefix, status, lifecycle timestamps. The plaintext is returned once at mint time and never again. The source and destinations console guide covers the mint / rotate / revoke lifecycle and the endpoint your apps point at.
  • Destinations (outbound) rows expose the subscription’s name, kind, target URL, event filter, status badge, and last-activity time — the same fields this guide’s table enumerates. Destination signing secrets follow the same once-only reveal rule as ingest secrets, with a seven-day dual-sign window when you rotate so the receiver can cut over without a delivery gap.
Every mutation the page exposes (mint/revoke ingest secrets, create/rotate/delete destinations, circuit reset, delivery retry, bulk replay, history backfill) is gated to owner, admin, or developer roles, and rendered through the same role-gating on both the page and the API. Members and viewers read the page but cannot change flow configuration. Design your team’s split on that contract: operators who only need to watch delivery health get viewer access; the recovery workflow (reset + replay) needs an admin-grade role.

​
See also