CDP integration console overview

The Integrations → CDP hub is the operator console for customer data flowing in and out of Orbit: inbound event ingest, outbound delivery, warehouse round-trips, identity resolution, schema and privacy governance, and live debugging. Deep-dive guides exist for a handful of those tabs; this page is the map of the whole console, with the connector catalogs and the backend endpoints behind each surface so you can reach the same surface from the UI or the API. Open it at Integrations → CDP in the dashboard. Two linked route tiles sit at the top — Tracking plan and Event schemas — followed by the full tab set this page tours.

1. What the console does

The page header states the two directions the console governs, and the two most-used tabs own them:

Source (inbound) — mints and rotates the per-tenant ingest secret your apps sign events with, and shows the ingest endpoint URL. Lifecycle states surface per row: active, rotating, revoked.
Destinations (outbound) — forwards Orbit events to your CDP, marketing platform, or any HMAC-verifying HTTPS receiver: Segment, RudderStack, mParticle, Hightouch, Marketo, GA4, Amplitude, or a Nango-routed OAuth platform (HubSpot, Salesforce, Braze, Iterable, Customer.io, Klaviyo, …) from the platform card grid, or a generic webhook.

Delivery health is first-class: every destination row carries a circuit-breaker badge (active, paused, circuit_open, disabled), openable from the row, plus a reset action when your receiver has recovered. Failed deliveries accumulate in the DLQ tab (grouped by destination, with single retry and bulk replay). Full self-service for these two tabs is in CDP integration console: source and destinations; DLQ operation has its own debugging guide. The rest of the console is organized below as seven tab groups. Every group names its tabs, the provider catalog it exposes, and the API endpoints the tab calls — so a reader who only ever used Source + Destinations can discover what else shipped.

2. Tour of the remaining tabs

Group 1 — Warehouse + reverse-ETL

Sources (reverse-ETL) — pull rows out of your warehouse (BigQuery) as CDP source records on a schedule: model-driven sources with sync-run history. Endpoints: GET /api/v1/cdp/reverse-etl (list), plus the sync-run and backfill surfaces.
Reverse ETL (BigQuery) — the BigQuery-specific wiring: connection, model pick, and mapping into profiles/events. Endpoint: GET /api/v1/cdp/reverse-etl/destinations (panel state) and GET /api/v1/cdp/reverse-etl.
Source catalog — the cloud-app source connector catalog (Salesforce, HubSpot, Stripe, Zendesk, Intercom, Jira, Shopify, Pipedrive, BambooHR, Workday, …) with per-connector live sync health. Endpoints: GET /api/v1/cdp/source-catalog, GET /api/v1/cdp/source-catalog/:connector_id/sync-status.
Destination catalog — the activation-side mirror: reverse-ETL warehouses (BigQuery, Snowflake, Redshift, Databricks, ClickHouse, PostgreSQL), streaming destinations, ad platforms, and messaging channels (Segment, Braze, Iterable, Klaviyo, Salesforce, HubSpot, Webhook, …). Endpoint: GET /api/v1/cdp/destination-catalog.
Warehouse credentials for reverse-ETL are managed from the same tab group — connections go through the destination catalog validate-config step before they are saved.

Group 2 — Schema governance (linked route tiles)

Tracking plan — declare the events your apps send and the expected property shape per event; runtime violations are captured and listed at ingest. Endpoints: GET /api/v1/cdp/tracking-plan, GET /api/v1/cdp/tracking-plan/violations, PATCH /api/v1/cdp/tracking-plan/settings. See CDP tracking plan.
Event schemas — enforce a JSON Schema per event type at ingest, choosing drop, warn, or ignore for invalid payloads. Endpoints: GET /api/v1/cdp/schemas, PATCH /api/v1/cdp/schemas/:event_type.

Group 3 — Identity

Identity resolution — priority-ordered rules that stitch identifiers (email, phone, external id) into one profile. Endpoint: GET /api/v1/cdp/identity-rules.
Identity graph — per-user stitched identifier chain with split support. Endpoint: GET /api/v1/cdp/profiles/by-user-id/:user_id/identity-graph.
Device graph — the anonymous-id device view. Endpoint: GET /api/v1/cdp/profiles/by-anonymous-id/:anonymous_id/device-graph.

The data catalog + identity rules guide covers day-to-day operation for rules priorities.

Group 4 — Privacy and governance

PII tokenization — tenant-driven tokenize/detokenize rules by data type for fields that must never travel downstream as plaintext. Endpoints: GET /api/v1/cdp/pii-tokenization, POST /api/v1/cdp/pii-tokenization/:type, DELETE /api/v1/cdp/pii-tokenization/:type, POST /api/v1/cdp/pii-tokenization/tokenize, POST /api/v1/cdp/pii-tokenization/detokenize.
PII vault — the backing store tokens resolve against. Endpoints: POST /api/v1/cdp/pii-vault/tokenize, POST /api/v1/cdp/pii-vault/detokenize.
Trait governance — classification and access policy per computed/composed trait (which audiences the trait may activate into). Endpoints: GET /api/v1/cdp/trait-governance, GET /api/v1/cdp/trait-governance/access, POST /api/v1/cdp/trait-governance/:trait_name.
Event property governance — classification per event property so sensitive fields are flagged before destinations receive them. Endpoints: GET /api/v1/cdp/event-property-governance, POST /api/v1/cdp/event-property-governance/:event_name/:property_name.
Data catalog — the inventory of traits and event properties the two governance tabs classify against. Endpoint: GET /api/v1/cdp/data-catalog.
Retention — per-target keep/discard windows for events and profiles. Endpoints: GET /api/v1/cdp/retention-policy, PATCH /api/v1/cdp/retention-policy/:target.
Erasure propagation — how a deletion reaches every destination, per-destination mode assignment, and status. Endpoints: GET /api/v1/cdp/erasure/destination-modes, PATCH /api/v1/cdp/erasure/destination-modes. See the erasure propagation guide.

All of these are workspace-owner controls: Orbit does not impose a platform-side privacy posture; every classification, retention window, and erasure mode is something your team sets, changes, or disables.

Group 5 — Operate and debug

Event debugger — a live tail of the raw ingest stream with per-field filters and payload introspection. Endpoint: GET /api/v1/cdp/events/debug.
DLQ — every delivery that failed a destination, grouped by destination, with single-row retry and bulk replay. Endpoints: GET /api/v1/cdp/dlq, POST /api/v1/cdp/deliveries/:id/retry, POST /api/v1/cdp/subscriptions/:id/replay-failed. The debugger + DLQ guide walks a push-break-replay loop.
Event export — export stored event history out of the workspace. Endpoint: POST /api/v1/cdp/events/export.
Data quality — freshness and anomaly surfacing over the ingest stream. Endpoint: GET /api/v1/cdp/data-quality.
Consent — the consent ledger: per-contact signal history and region/toolkit defaults surfaced for audit. Wired through the consent-propagation endpoints.
Offer catalog — the offerset decisioning feeds draw from, with channels and eligibility metadata. Endpoints: GET /api/v1/cdp/offers, PATCH /api/v1/cdp/offers/:id.

Group 6 — File exchange

File sources (inbound) — bulk CSV/Parquet/JSON ingest into profiles/events, from the file-source catalog (SFTP, cloud storage, uploads). Endpoints: GET /api/v1/cdp/file-sources, POST /api/v1/cdp/file-sources/:source_id/validate-config.
File import (object storage sources) — pull from your own GCS/S3/Vercel-Blob store on a schedule. Endpoints: GET /api/v1/cdp/object-storage-source-config/:provider, PATCH /api/v1/cdp/object-storage-source-config/:provider.
File export (object storage destinations) — write event/profile extracts out to object storage. Endpoints: GET /api/v1/cdp/object-storage-destinations/:provider, PATCH /api/v1/cdp/object-storage-destinations/:provider.
Data share (warehouse) — publish the interaction data contract (messages, conversations, events) into your warehouse with a schema contract and backfill. Endpoints: GET /api/v1/cdp/interaction-data-share/schema-contract, GET /api/v1/cdp/interaction-data-share/:provider, POST /api/v1/cdp/interaction-data-share/:provider/backfill.

Group 7 — Apps, enrichment, activation

CRM sync — bidirectional sync into a CRM (Salesforce, HubSpot, Pipedrive, …) with per-destination run history. Endpoints: GET /api/v1/cdp/crm-sync/config, PATCH /api/v1/cdp/crm-sync/config/:destination, GET /api/v1/cdp/crm-sync/runs.
ERP sync — the same shape into ERP systems (NetSuite, SAP, Workday, QuickBooks, …). Endpoints: GET /api/v1/cdp/erp-sync/config, GET /api/v1/cdp/erp-sync/runs.
BI tools — connection-profile catalog for Looker / Tableau / PowerBI / Metabase-style tools. Endpoint: GET /api/v1/cdp/bi-connectors.
Enrichment — provider catalog (Clearbit, People Data Labs, HubSpot Breeze-class sources) plus activation and broker preview/enrich. Endpoints: GET /api/v1/cdp/enrichment-catalog, POST /api/v1/cdp/enrichment-catalog/:provider_id/broker-enrich.
Clean room — overlap and match runs against a partner workspace. Endpoint: POST /api/v1/cdp/clean-room/match.
Conversion forwarding — forward server-side conversions to ad platforms (Meta CAPI, TikTok Events API) with per-platform config and forwarding history. Endpoints: GET /api/v1/cdp/conversions/config, PATCH /api/v1/cdp/conversions/config/:platform, GET /api/v1/cdp/conversions/forwards. Convenience tabs Meta CAPI and TikTok Events pre-filter to the matching platform.
Streaming — low-latency push destinations for event streams. Endpoints: GET /api/v1/cdp/streaming-destinations/:provider, PATCH /api/v1/cdp/streaming-destinations/:provider.
Segment — the Segment-specific destination wiring, kept as its own tab for the most common setup.
Transforms — event-transform functions applied between ingest and delivery.
Trait explorer — browse computed/composed trait values per profile.
Event bus sources — subscribe to an external event bus as an ingest source.

3. Complication guardrails — and how to relax them

“Complication” on this page means circuit-breaker guardrails: the console refuses to keep hammering a receiver that is failing, so a broken destination does not drain your event throughput.

How a destination opens. Consecutive delivery failures flip the subscription to circuit_open; new dispatches skip it until you reset. The badge on each row in Destinations (outbound) shows the state, and the DLQ tab collects the failures that led there.
Reset. From the destination row’s actions, or POST /api/v1/cdp/subscriptions/:id/reset-circuit. Fix the receiver first — replay routes through the same circuit check, so a still-broken endpoint only accumulates more rows.
Pause instead of reset. Set the subscription to paused (PATCH /api/v1/cdp/subscriptions/:id) when you want delivery stopped entirely rather than guarded; unpause resumes normal flow.
Per-destination event filters and sampling. Narrow the event-name filter on the subscription (PATCH /api/v1/cdp/subscriptions/:id) to lower the volume that can trip the breaker instead of turning the breaker off.
What you cannot disable. The circuit guard itself always runs; the tenant knob is pause, not an off switch — a genuinely open receiver stays open until reset, so partial outages never silently bleed events.

4. cURL patterns for the two most-used tabs

The Source and Destinations tabs are UI over the admin endpoints below — the same calls the page issues, so cURL parity is one-to-one.

Mint an ingest secret (Source)

curl -X POST "https://api.orbit.devotel.io/api/v1/cdp/secrets" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json"

The plaintext secret is returned exactly once — capture it now. List lifecycle (active / rotating / revoked) and last-used timestamps:

curl "https://api.orbit.devotel.io/api/v1/cdp/secrets" \
  -H "Authorization: Bearer $API_TOKEN"

Create a destination (Destinations)

curl -X POST "https://api.orbit.devotel.io/api/v1/cdp/subscriptions" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Warehouse webhook",
    "kind": "webhook",
    "target_url": "https://receiver.example.com/orbit",
    "events": ["contact.created", "message.delivered"]
  }'

List destinations and read circuit badges:

curl "https://api.orbit.devotel.io/api/v1/cdp/subscriptions" \
  -H "Authorization: Bearer $API_TOKEN"

Reset a tripped circuit after the receiver recovers:

curl -X POST "https://api.orbit.devotel.io/api/v1/cdp/subscriptions/$SUBSCRIPTION_ID/reset-circuit" \
  -H "Authorization: Bearer $API_TOKEN"

WhatsApp

Guides

Messaging Controls

Audience & Support Tools

CDP integration console overview: every tab, catalog, and endpoint on Integrations → CDP

CDP integration console overview

1. What the console does

2. Tour of the remaining tabs

Group 1 — Warehouse + reverse-ETL

Group 2 — Schema governance (linked route tiles)

Group 3 — Identity

Group 4 — Privacy and governance

Group 5 — Operate and debug

Group 6 — File exchange

Group 7 — Apps, enrichment, activation

3. Complication guardrails — and how to relax them

4. cURL patterns for the two most-used tabs

Mint an ingest secret (Source)

Create a destination (Destinations)

See also

​CDP integration console overview

​1. What the console does

​2. Tour of the remaining tabs

​Group 1 — Warehouse + reverse-ETL

​Group 2 — Schema governance (linked route tiles)

​Group 3 — Identity

​Group 4 — Privacy and governance

​Group 5 — Operate and debug

​Group 6 — File exchange

​Group 7 — Apps, enrichment, activation

​3. Complication guardrails — and how to relax them

​4. cURL patterns for the two most-used tabs

​Mint an ingest secret (Source)

​Create a destination (Destinations)

​See also

CDP integration console overview

1. What the console does

2. Tour of the remaining tabs

Group 1 — Warehouse + reverse-ETL

Group 2 — Schema governance (linked route tiles)

Group 3 — Identity

Group 4 — Privacy and governance

Group 5 — Operate and debug

Group 6 — File exchange

Group 7 — Apps, enrichment, activation

3. Complication guardrails — and how to relax them

4. cURL patterns for the two most-used tabs

Mint an ingest secret (Source)

Create a destination (Destinations)

See also