> ## 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.

# CDP destinations: subscribe outbound receivers and hold the circuit breaker

> Deep-operate the Destinations (outbound) half of Integrations → CDP — subscribe Segment, RudderStack, mParticle, Hightouch, or a generic webhook receiver, read the delivery circuit breaker, and run a clean reset-plus-replay recovery.

# CDP destinations: outbound subscriptions and the circuit breaker

The **Integrations → CDP** page carries two event-flow directions. The [source and destinations console guide](/guides/cdp-source-and-destinations) 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:

| Badge            | Meaning                                                                                                                                                                   |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Active**       | Deliveries are flowing.                                                                                                                                                   |
| **Paused**       | Delivery is held by an operator (the pause action on the row). New events queue for the destination; nothing dispatches until it resumes.                                 |
| **Circuit open** | Five consecutive delivery failures tripped the breaker. The destination is skipped by new dispatches until it recovers, so a dead receiver doesn't drag the shared queue. |
| **Disabled**     | The subscription is off — no dispatch, no queue.                                                                                                                          |

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](/guides/cdp-ingest-signing) 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](/guides/cdp-event-debugger-and-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](/guides/cdp-tracking-plan).
* 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](/guides/cdp-source-and-destinations) 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

* [CDP integration console: source and destinations](/guides/cdp-source-and-destinations) — both halves of the page operated together, including the ingest-side secret lifecycle this guide leaves out
* [CDP tracking plan](/guides/cdp-tracking-plan) — declares what the inbound half accepts
* [Sign CDP ingest requests without a client SDK](/guides/cdp-ingest-signing) — the HMAC scheme destinations reuse on the outbound side
* [CDP event debugger and DLQ](/guides/cdp-event-debugger-and-dlq) — the failure-backlog surface the **Replay failed** action drains
* [CDP event model](/concepts/cdp-event-model) — the event shape every destination payload carries