​

CDP connector catalogs: sources, destinations, enrichment, BI, CRM/ERP, offers, and the clean room

1. Discover — list connectors and filter by category / status / search. Each row is a typed, honest-maturity record: ga (wired to a live backend today), beta (transport live, gaps in metadata), or coming_soon (no activatable provider yet).
2. Validate a config — every catalog ships a POST .../validate-config route that checks an operator-submitted connect form against the connector’s field spec without persisting anything and without the redirect-credentialed call, and echoes back a credential-redacted copy.
3. Activate — on the source catalog, mint the OAuth connect URL (POST /connect), kick a managed pull (POST /sync), and watch live pull state (GET /sync-status).
4. Audit — CRM/ERP sync, decisioning, and history surfaces keep a capped sync-run ledger; every mutation lands in the tamper-evident audit chain.

​

1. Source catalog — SaaS/cloud-app pull connectors

• POST /api/v1/cdp/source-catalog/:connector_id/connect — mint the OAuth/authorize URL so you link the upstream provider via Nango. A coming_soon connector returns 409 (no activatable backend yet).
• POST /api/v1/cdp/source-catalog/:connector_id/sync — trigger a managed pull on the connection you just wired. 409 when the provider is not connected.
• GET /api/v1/cdp/source-catalog/:connector_id/sync-status — the live view: connected? errored? last synced at? per-sync row counts.
• GET /api/v1/cdp/source-catalog/:connector_id/activation — the read the connect surface uses to render a Connect button vs a Request access CTA: activatable, the wired managed-sync provider and schedule, the connect URL, and which advertised objects are live_objects vs roadmap_objects.
• POST /api/v1/cdp/source-catalog/:connector_id/validate-config — structural connect-form validation. Check an operator-submitted connect form against the connector’s field spec without persisting and without reaching the provider; the echo is credential-redacted.

​

Worked example — connect HubSpot

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/source-catalog/hubspot/connect \
  -H "X-API-Key: dv_live_sk_your_key_here"
# → { "connectUrl": "https://...nango.dev/oauth...&connection_id=hubspot__org_abc" }

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/source-catalog/hubspot/sync \
  -H "X-API-Key: dv_live_sk_your_key_here"
curl -s https://api.orbit.devotel.io/api/v1/cdp/source-catalog/hubspot/sync-status \
  -H "X-API-Key: dv_live_sk_your_key_here"

​

2. Destination catalog — outbound connectors

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/destination-catalog/customer_io/validate-config \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "sk-acme-123",
    "site_id": "12345-ab"
  }'

​

3. Enrichment — Clearbit, ZoomInfo, Apollo, FullContact

• GET /api/v1/cdp/enrichment-catalog/:provider_id/scoring-signals — which firmographic account-scoring inputs the provider would supply, replacing the contact-count proxy default.
• POST /api/v1/cdp/enrichment-catalog/:provider_id/validate-config — structural validation of a connect form, credential-redacted echo.

​

Worked example — preview an enrichment lookup

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/enrichment-catalog/clearbit/broker-preview \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "raw": { "company_name": "Acme Corp", "employee_count": 450 },
    "margin_pct": 12,
    "units": 1
  }'

​

4. BI tools — Tableau, Power BI, Looker, Superset, Metabase

​

Worked example — generate a Tableau / BigQuery profile

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/bi-connectors/tableau/connection-profile \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "warehouse": "bigquery" }'

​

5. CRM sync — segment → SaaS object writes

• GET /api/v1/cdp/crm-sync/config — every destination’s mapping: enabled, Nango connection id, object_type, upsert identifier_field, field_map, segment_id, schedule_minutes, and the last-run status.
• PATCH /api/v1/cdp/crm-sync/config/:destination — wire or adjust one destination. Only the supplied keys are touched; sibling destinations and other settings keys are preserved. object_type is checked against the destination’s whitelist.
• POST /api/v1/cdp/crm-sync/run/:destination — run one sync now from a supplied batch of profiles.
• GET /api/v1/cdp/crm-sync/runs — bounded sync-run history, newest first.

​

Worked example — wire HubSpot, then kick a run

curl -X PATCH https://api.orbit.devotel.io/api/v1/cdp/crm-sync/config/hubspot \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "object_type": "contact",
    "identifier_field": "email",
    "segment_id": "seg_champions",
    "field_map": {
      "email": "email",
      "first_name": "firstname",
      "last_name": "lastname",
      "company": "company"
    },
    "schedule_minutes": 360
  }'

​

6. ERP sync — segment → finance-system object writes

curl -X PATCH https://api.orbit.devotel.io/api/v1/cdp/erp-sync/config/netsuite \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "object_type": "Customer",
    "identifier_field": "entityId",
    "segment_id": "seg_active_customers",
    "field_map": { "entity_id": "entityId", "email": "email" }
  }'

​

7. Offer catalog — next-best-offer constraints, persisted

• GET /api/v1/cdp/offers — keyset-paginated list, ?active_only=true filters to the partial index.
• POST /api/v1/cdp/offers — upsert keyed on offer_id.
• DELETE /api/v1/cdp/offers/:id — remove a row.

​

Worked example — upsert a restricted offer

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/offers \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "offer_id": "offer_summer_champions",
    "value": 25,
    "priority": 10,
    "constraints": {
      "starts_at": 1754102400000,
      "expires_at": 1756799999999,
      "max_per_contact": 1,
      "budget_remaining": 5000,
      "cost_per_redemption": 25,
      "exclusivity_group": "summer-2025",
      "required_segments": ["seg_champions"],
      "channels": ["sms"],
      "min_cart_value": 50
    }
  }'

​

8. Clean room — two-party hashed overlap

​

Worked example — overlap with a media partner

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/clean-room/match \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "party": { "records": [{ "identifier": "alice@acme.com", "consent": true }] },
    "partner": { "hashed_identifiers": ["<hashed-digest>", "<hashed-digest>"] },
    "label": "partner overlap run",
    "min_match_threshold": 20
  }'

​

9. Streaming, file, and event-bus source catalogs

• Streaming SDKs — GET /api/v1/cdp/streaming-sources registers first-class real-time sources for server, mobile, and web SDKs plus the raw HTTP ingest endpoints (/cdp/v1/:ingest_id/{track,identify,page,screen,group,alias,batch}). Status is honest here: ga only when the packaged SDK ships today.
• File sources — GET /api/v1/cdp/object-storage-sources (and the sibling file-source catalog) for object-storage file-drop ingestion — drop CSV / JSON / Parquet events or profiles in your own S3 / GCS / Azure Blob bucket on a schedule. Each connector ships its own validate-config sibling.
• Event bus sources — GET /api/v1/cdp/event-bus-sources for Kafka topic / Kinesis stream / Pub/Sub subscription sources (the consume-side mirror of the already-shipped event-bus destinations). Also ships POST .../preview-message and POST .../consume-batch for a non-persistent soak test before wiring the continuous consumer.

​

10. Permissions and audit