Unified Customer Data Platform API: Access Customer Profiles, Segments, and Events Across CDPs

August 4, 2026

Unified now supports a new category: Customer Data Platform.

The Unified CDP API gives you one CDP API to read customer profiles, audience segments, and the sources and destinations around them across the customer data platforms your end-customers already run. Every request is routed directly to the customer's CDP at the moment you make it, so what you read is what exists in their platform right now. Nothing is cached and no end-customer data is stored.

Object and field coverage differs by integration, because each platform's own API determines what Unified can support. Field support, webhook support, and list parameters are documented per integration.

Why every CDP integration is a different integration

Customer data platforms all do four things: take data in, resolve it to a person, group those people, and send the groups somewhere. Each one names those four things differently and models them differently in its API, so supporting a second CDP is close to a second integration build rather than an extension of the first.

What changes when you build against one CDP API

What you can build with the CDP API

• Audience pickers that let a customer choose a segment from their own CDP inside your product, alongside the campaign and engagement data your marketing integrations already return
• Customer 360 views that read profile identity and current segment membership in one request
• Identity resolution features that read a person's identifiers across email, user ID, anonymous ID, device ID, phone, CRM ID, and loyalty ID
• Onboarding surfaces that show a customer which sources and destinations their CDP already has configured
• Change-driven features that react to a new or updated segment through a webhook rather than a polling schedule
• AI agents that read profile traits and segment membership at request time to recommend a next action

The last one is why this category matters for AI products specifically. An agent making a decision about a customer needs the profile as it stands at the moment of the call. A profile copied overnight is a guess about the present.

Which customer data platforms does Unified support?

The CDP category covers 11 integrations:

• Adobe Experience Platform
• Amperity
• Bloomreach Engagement (Exponea)
• BlueConic
• journy.io
• Lytics
• mParticle
• Salesforce Data Cloud
• Tealium
• Treasure Data
• Twilio Segment

What objects does the Unified CDP API normalize?

The CDP API provides six normalized objects:

• Profile — a person, with contact fields, a typed identifiers array, a segments array carrying current membership with join and expiry dates, a consent array holding status per purpose, metadata for the profile's traits, and is_anonymous to separate known customers from unresolved visitors
• Segment — a defined group, with its definition, a type of USERS, ACCOUNTS, or LINKED, compute_mode for whether membership is calculated continuously or in batches, slug as the handle that identifies membership in profiles and destinations, size, and is_active state
• Event — a behavioural or identity record, with a type of TRACK, PAGE, SCREEN, IDENTIFY, GROUP, or ALIAS, occurred_at for when the event happened as against created_at for when it was ingested, profile_id, the same typed identifiers array carried on Profile, and metadata holding the event properties
• Source — where data arrives from, with a slug handle, a type, is_enabled, and a direction of SOURCE, DESTINATION, or BIDIRECTIONAL
• Destination — where data is sent to, sharing the shape of Source and distinguished by direction. Where the same entry both imports and exports, direction returns BIDIRECTIONAL
• Activation — the sync job linking a segment, a source, and a destination, with a status of ACTIVE, PAUSED, ERROR, or PENDING, a schedule string, last_run_at, and is_enabled

Unified normalizes the shared concepts and provides access to platform-specific fields through the raw field on every object.

How you read CDP data

Every CDP object is listed at GET /cdp/{connection_id}/{object} and retrieved at GET /cdp/{connection_id}/{object}/{id}, so the request shape is the same whichever object you are after and whichever platform the connection points at.

List requests share one set of parameters across all six objects: limit and offset for paging, sort and order, query for a text search such as an email address or a name, fields to narrow the response, and updated_gte to return only records changed since a timestamp, which is what makes an incremental read possible without a stored cursor. Event adds profile_id, and Activation adds segment_id and destination_id.

Where a platform's own API does not support an object, the request returns 501 Not Implemented rather than an empty list, so a missing capability is distinguishable from a customer with no data.

What one profile request returns

Profile embeds identity, traits, and segment membership inside the record, so one request returns an assembled profile rather than a starting point for further calls.

Each entry in identifiers carries a type (EMAIL, USER_ID, ANONYMOUS_ID, DEVICE_ID, PHONE, CRM_ID, LOYALTY_ID, OTHER), a value, an is_primary flag, the source that supplied it, and an encoding field recording whether the value is raw or hashed. That last field is what makes an identifier usable downstream, where ad platforms expect SHA-256 rather than plaintext and a product that cannot tell the difference has to guess.

segments is an array on the profile, not a set of IDs to resolve separately. Each entry carries segment_id, the segment name, joined_at, and expires_at, so you can tell which audiences a person belongs to, how long they have been in each, and when membership lapses.

consent records status per purpose rather than as a single flag, pairing a purpose such as marketing or analytics with a status of GRANTED, DENIED, or PENDING and the date it last changed.

metadata carries the profile's traits, each with a slug, a typed format, and a namespace recording whether the trait was computed, derived from an event, or captured from a visitor session. The same shape carries event properties on Event.

Which changes can you receive as webhooks?

Unified detects changes on profiles and segments and delivers events to your endpoint, so a product can react to a change rather than poll for it. The available events are cdp_profile_created, cdp_profile_updated, cdp_profile_deleted, cdp_segment_created, cdp_segment_updated, cdp_segment_deleted, and cdp_event_created.

Support varies by integration, and sources, destinations, and activations have no webhook events at launch, so anything built on those objects reads on a schedule you set. Webhook support is documented per integration.

Example build

An audience picker inside your product, so a customer can target a segment from their own CDP:

1. Each customer authorizes their CDP through Unified's authorization component. You store one connection ID per customer.
2. You list Segment objects for that connection and render the picker from id and name.
3. Where the platform returns more, you show more: description, size, definition, and compute_mode so a customer can see whether membership is continuous or batched.
4. You subscribe to cdp_segment_created and cdp_segment_updated so the picker reflects changes the customer makes in their CDP without you polling for them.
5. When the customer picks a segment, you store its id against their configuration and read Profile.segments to check membership.

The same code runs against every customer. What varies is how much detail each platform returns, not whether the feature works.

Real-time by design

Every request is executed directly against the source API rather than served from a stored copy.

Requests are stateless. No end-customer profile data is cached, synced, or stored at rest on the request path. Traffic is regionalized across the US, EU, and AU to support data residency requirements, which matters more in this category than most: customer data platforms hold the identity and consent records that carry the heaviest compliance obligations.

The CDP API is one of 31 categories and 683 integrations on Unified, and is available on all plans.

→ Start your 30-day free trial → Book a demo

Frequently asked questions

What is a unified CDP API?

A unified CDP API provides one interface for reading customer profile, segment, and audience data across multiple customer data platforms. Instead of building against Twilio Segment, Adobe Experience Platform, and Lytics separately, developers integrate once and work with the same object names and fields regardless of which platform an end-customer runs.

Which CDP objects and fields are supported on which platforms?

Coverage differs by integration because each platform's own API determines what Unified can support, and it changes as integrations are added and extended. The Supported Integrations page in the documentation lists field support, webhook support, and list parameters for every integration in the category, and is the current source rather than any figure quoted elsewhere.

How does the Unified CDP API handle identity across platforms?

The Unified Profile object carries a typed identifiers array where each entry records the identifier type, its value, whether it is primary, the source that supplied it, and whether the value is raw or hashed. Eight types are supported: email, user ID, anonymous ID, device ID, phone, CRM ID, loyalty ID, and other. The same array appears on Event.

Does Unified store customer profile data?

No. Unified does not store end-customer data at rest on the request path. Each request is executed directly against the customer's CDP and the response is returned without being cached or written to a database, which keeps profile, consent, and identity data inside the platform the customer already chose.

Author

Written for Unified.to by Mallory Greene

About the author: Mallory Greene is a writer specializing in generative engine optimization (GEO) and content, through her practice Search Everywhere. She covers integration infrastructure and technical content across Unified.to's technical content library. Based in Toronto.