Skip to Content
DevelopersCDP Integration

CDP Integration

This guide explains the developer-facing contract for ResultFly CDP integrations.

If you are sending customer data into ResultFly, there are three important ideas to keep separate:

  1. Profiles store customer-level facts.
  2. Identifiers resolve incoming data to the right profile.
  3. Campaign variables belong to runtime flow execution and are not the same thing as CDP data.

1. Integration Surfaces

ResultFly CDP integrations use two main technical surfaces:

  • Server-to-server ingest for customer events and backend-controlled data flows.
  • Runtime APIs for campaign execution under an authenticated user context.

Do not use the browser JavaScript bridge as a substitute for CDP ingest. The JavaScript API is for host-page integration and analytics-style event forwarding, not for canonical customer-data ingestion.

2. Identity Model

The first CDP delivery uses canonical identifier types:

  • EXTERNAL
  • EMAIL
  • PHONE
  • DEVICE_KEY

Integration rules:

  • EXTERNAL is the primary path for customer-controlled upstream IDs.
  • EMAIL and PHONE may participate in profile matching.
  • DEVICE_KEY is useful for device-bound or app-bound recognition.
  • Matching is deterministic and precedence-based, not fuzzy or score-based.

Normalization matters:

  • emails are trimmed and lowercased
  • phone values are normalized before matching

3. Channel Model vs Identity Model

Do not model communication readiness directly from profile fields or identity rows.

Use the channel model for:

  • current consent status
  • reachability
  • active endpoint ownership
  • channel-specific export logic

Use the identity model for:

  • resolving the customer profile
  • deterministic merges
  • future lookup consistency

4. Event Ingestion Contract

Incoming events are accepted through a governed contract.

Each event must include:

  • source
  • externalEventId
  • eventType
  • occurredAt
  • identity
  • properties

Each event type must be registered in the CDP contract layer before production ingest should rely on it. Registered properties carry metadata such as:

  • type
  • required vs optional
  • filterable in segments
  • usable in derived attributes

This keeps downstream segments and exports stable.

5. Idempotency and Retries

CDP ingest is idempotent at the event level.

The main rule is:

  • the same (tenant, source, externalEventId) must not apply business effects twice

This means your integration should reuse the same event ID when retrying after:

  • network timeouts
  • 5xx responses
  • worker or queue uncertainty

6. Authentication

Use server-side API keys for ingest and administrative CDP operations.

Use user-context JWTs only for runtime APIs that act on behalf of a specific participant during campaign execution.

Do not expose ingest API keys in client-side code.

7. Choosing Between CDP and Campaign Variables

Send data into the CDP when:

  • it comes from backend systems
  • it must be reusable across campaigns
  • it should appear in segments or exports
  • it describes the customer beyond one runtime session

Use campaign variables when:

  • the value is part of campaign execution logic
  • it is scoped to one campaign
  • it does not need to become part of the customer-data model
JavaScript APICampaign Variables