Descriptors endpoint
Schemas define the structure of data entities but don’t specify how any datasets created from these schemas relate to each other. In Adobe Experience Platform, you can use descriptors to describe these relationships and add interpretive metadata to a schema.
Descriptors are tenant-level metadata objects applied to schemas in Adobe Experience Platform. They define structural relationships, keys, and behavioral fields (such as timestamps or versioning) that influence how data is validated, joined, or interpreted downstream.
A schema can have one or more descriptors. Each descriptor defines a @type
and the sourceSchema
it applies to. The descriptor automatically applies to all datasets created from that schema.
In Adobe Experience Platform, a descriptor is metadata that adds behavioral rules or structural meaning to a schema.
There are several types of descriptors, including:
- Identity descriptor – marks a field as an identity
- Primary key descriptor – enforces uniqueness
- Relationship descriptor – defines a foreign-key join
- Alternate display info descriptor – lets you rename a field in the UI
- Version and timestamp descriptors – track event ordering and change detection
The /descriptors
endpoint in the Schema Registry API allows you to programmatically manage descriptors within your experience application.
Getting started
The endpoint used in this guide is part of the Schema Registry API. Before continuing, please review the getting started guide for links to related documentation, a guide to reading the sample API calls in this document, and important information regarding required headers that are needed to successfully make calls to any Experience Platform API.
In addition to standard descriptors, the Schema Registry supports descriptor types for model-based schemas, such as primary key, version and timestamp. These enforce uniqueness, control versioning, and define time-series fields at the schema level. If you are unfamiliar with model-based schemas, review the Data Mirror overview and model-based schemas technical reference before continuing.
Retrieve a list of descriptors list
You can list all descriptors that have been defined by your organization by making a GET request to /tenant/descriptors
.
API format
GET /tenant/descriptors
Request
curl -X GET \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Accept: application/vnd.adobe.xdm-link+json'
The response format depends on the Accept
header sent in the request. Notice that the /descriptors
endpoint uses Accept
headers that are different from all other endpoints in the Schema Registry API.
Accept
headers that replace xed
with xdm
, and also offer a link
option that is unique to descriptors. The proper Accept
headers have been included in the examples calls below, but take extra caution to ensure that the correct headers are being used when working with descriptors.Accept
headerapplication/vnd.adobe.xdm-id+json
application/vnd.adobe.xdm-link+json
application/vnd.adobe.xdm+json
application/vnd.adobe.xdm-v2+json
Accept
header must be used to use paging capabilities.Response
The response includes an array for each descriptor type that has defined descriptors. In other words, if there are no descriptors of a certain @type
defined, the registry will not return an empty array for that descriptor type.
When using the link
Accept
header, each descriptor is shown as an array item in the format /{CONTAINER}/descriptors/{DESCRIPTOR_ID}
{
"xdm:alternateDisplayInfo": [
"/tenant/descriptors/85dc1bc8b91516ac41163365318e38a9f1e4f351",
"/tenant/descriptors/49bd5abb5a1310ee80ebc1848eb508d383a462cf",
"/tenant/descriptors/b3b3e548f1c653326bcf5459ceac4140fc0b9e08"
],
"xdm:descriptorIdentity": [
"/tenant/descriptors/f7a4bc25429496c4740f8f9a7a49ba96862c5379"
],
"xdm:descriptorOneToOne": [
"/tenant/descriptors/cb509fd6f8ab6304e346905441a34b58a0cd481a"
]
}
Look up a descriptor lookup
To view the details of a specific descriptor, send a GET request using its @id
.
API format
GET /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
of the descriptor you want to look up.Request
The following request retrieves a descriptor by its @id
value. Descriptors are not versioned, therefore no Accept
header is required in the lookup request.
curl -X GET \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/f3a1dfa38a4871cf4442a33074c1f9406a593407 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}'
Response
A successful response returns the details of the descriptor, including its @type
and sourceSchema
, as well as additional information that varies depending on the type of descriptor. The returned @id
should match the descriptor @id
provided in the request.
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false,
"createdUser": "{CREATED_USER}",
"imsOrg": "{ORG_ID}",
"createdClient": "{CREATED_CLIENT}",
"updatedUser": "{UPDATED_USER}",
"created": 1548899346989,
"updated": 1548899346989,
"meta:containerId": "tenant",
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
Create a descriptor create
You can create a new descriptor by making a POST request to the /tenant/descriptors
endpoint.
API format
POST /tenant/descriptors
Request
The following request defines an identity descriptor on an “email address” field in a sample schema. This tells Experience Platform to use the email address as an identifier to help stitch together information about the individual.
curl -X POST \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}'
Response
A successful response returns HTTP status 201 (Created) and the details of the newly created descriptor, including its @id
. The @id
is a read-only field assigned by the Schema Registry and used for referencing the descriptor in the API.
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false,
"meta:containerId": "tenant",
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
Update a descriptor put
You can update a descriptor by including its @id
in the path of a PUT request.
API format
PUT /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
of the descriptor you want to update.Request
This request essentially rewrites the descriptor, so the request body must include all fields required for defining a descriptor of that type. In other words, the request payload to update (PUT) a descriptor is the same as the payload to create (POST) a descriptor of the same type.
The following example updates an identity descriptor to reference a different xdm:sourceProperty
(mobile phone
) and change the xdm:namespace
to Phone
.
curl -X PUT \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/f3a1dfa38a4871cf4442a33074c1f9406a593407 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/mobilePhone/number",
"xdm:namespace": "Phone",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}'
Response
A successful response returns HTTP status 201 (Created) and the @id
of the updated descriptor (which should match the @id
sent in the request).
{
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
Performing a lookup (GET) request to view the descriptor shows that the fields have now been updated to reflect the changes sent in the PUT request.
Delete a descriptor delete
Occasionally you may need to remove a descriptor that you have defined from the Schema Registry. This is done by making a DELETE request referencing the @id
of the descriptor that you wish to remove.
API format
DELETE /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
of the descriptor you want to delete.Request
curl -X DELETE \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/ca921946fb5281cbdb8ba5e07087486ce531a1f2 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}'
Response
A successful response returns HTTP status 204 (No Content) and a blank body.
To confirm the descriptor has been deleted, you can perform a lookup request against the descriptor @id
. The response returns HTTP status 404 (Not Found) because the descriptor has been removed from the Schema Registry.
Appendix appendix
The following section provides additional information regarding working with descriptors in the Schema Registry API.
Defining descriptors defining-descriptors
The following sections provide an overview of available descriptor types, including the required fields for defining a descriptor of each type.
Identity descriptor identity-descriptor
An identity descriptor signals that the “sourceProperty” of the “sourceSchema” is an Identity field as described by Experience Platform Identity Service.
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema":
"https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}
@type
xdm:descriptorIdentity
.xdm:sourceSchema
$id
URI of the schema where the descriptor is being defined.xdm:sourceVersion
xdm:sourceProperty
xdm:namespace
id
or code
value of the identity namespace. A list of namespaces can be found using the Identity Service API.xdm:property
xdm:id
or xdm:code
, depending on the xdm:namespace
used.xdm:isPrimary
Friendly name descriptor friendly-name
Friendly name descriptors allow a user to modify the title
, description
, and meta:enum
values of the core library schema fields. Especially useful when working with “eVars” and other “generic” fields that you wish to label as containing information specific to your organization. The UI can use these to show a more friendly name or to only show fields that have a friendly name.
{
"@type": "xdm:alternateDisplayInfo",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/274f17bc5807ff307a046bab1489fb18",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/xdm:eventType",
"xdm:title": {
"en_us": "Event Type"
},
"xdm:description": {
"en_us": "The type of experience event detected by the system."
},
"meta:enum": {
"click": "Mouse Click",
"addCart": "Add to Cart",
"checkout": "Cart Checkout"
},
"xdm:excludeMetaEnum": {
"web.formFilledOut": "Web Form Filled Out",
"media.ping": "Media ping"
}
}
@type
xdm:alternateDisplayInfo
.xdm:sourceSchema
$id
URI of the schema where the descriptor is being defined.xdm:sourceVersion
xdm:sourceProperty
/
) and not end with one. Do not include properties
in the path (for example, use /personalEmail/address
instead of /properties/personalEmail/properties/address
).xdm:title
xdm:description
meta:enum
xdm:sourceProperty
is a string field, meta:enum
can be used to add suggested values for the field in the Segmentation UI. It is important to note that meta:enum
does not declare an enumeration or provide any data validation for the XDM field.This should only be used for core XDM fields defined by Adobe. If the source property is a custom field defined by your organization, you should instead edit the field’s
meta:enum
property directly through a PATCH request to the field’s parent resource.meta:excludeMetaEnum
xdm:sourceProperty
is a string field that has existing suggested values provided under a meta:enum
field, you can include this object in a friendly name descriptor to exclude some or all of these values from segmentation. The key and value for each entry must match those included in the original meta:enum
of the field in order for the entry to be excluded.Relationship descriptor relationship-descriptor
Relationship descriptors describe a relationship between two different schemas, keyed on the properties described in xdm:sourceProperty
and xdm:destinationProperty
. See the tutorial on defining a relationship between two schemas for more information.
Use these properties to declare how a source field (foreign key) relates to a destination field (primary key or candidate key).
xdm:sourceProperty
) that references a key field in another schema. A candidate key is any field (or set of fields) in the destination schema that uniquely identifies a record and can be used instead of the primary key.The API supports two patterns:
xdm:descriptorOneToOne
: standard 1:1 relationship.xdm:descriptorRelationship
: general pattern for new work and model-based schemas (supports cardinality, naming, and non-primary key targets).
One-to-one relationship (standard schemas)
Use this when maintaining existing standard-schema integrations that already rely on xdm:descriptorOneToOne
.
{
"@type": "xdm:descriptorOneToOne",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/parentField/subField",
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:destinationVersion": 1,
"xdm:destinationProperty": "/parentField/subField"
}
The following table describes the fields required to define a one-to-one relationship descriptor.
@type
xdm:descriptorOneToOne
, unless you have access to Real-Time CDP B2B edition. With B2B edition you have the option to use xdm:descriptorOneToOne
or xdm:descriptorRelationship
.xdm:sourceSchema
$id
URI of the schema where the descriptor is being defined.xdm:sourceVersion
xdm:sourceProperty
xdm:destinationSchema
$id
URI of the reference schema this descriptor is defining a relationship with.xdm:destinationVersion
xdm:destinationProperty
General relationship (model-based schemas and recommended for new projects)
Use this descriptor for all new implementations and for model-based schemas. It allows you to define the relationship’s cardinality (such as one-to-one or many-to-one), specify relationship names, and link to a destination field that is not the primary key (non-primary key).
The following examples show how to define a general relationship descriptor.
Minimal example:
This minimal example includes only the required fields to define a many-to-one relationship between two schemas.
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceProperty": "/customer_ref",
"xdm:sourceVersion": 1,
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:cardinality": "M:1"
}
Example with all optional fields:
This example includes all optional fields, such as relationship names, display titles, and an explicit non-primary key destination field.
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/customer_ref",
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:destinationProperty": "/customer_id",
"xdm:sourceToDestinationName": "CampaignToCustomer",
"xdm:destinationToSourceName": "CustomerToCampaign",
"xdm:sourceToDestinationTitle": "Customer campaigns",
"xdm:destinationToSourceTitle": "Campaign customers",
"xdm:cardinality": "M:1"
}
Choosing a relationship descriptor
Use the following guidelines to decide which relationship descriptor to apply:
xdm:descriptorRelationship
xdm:descriptorOneToOne
unless you need features supported only by xdm:descriptorRelationship
.1:1
, 1:0
, M:1
, M:0
)xdm:descriptorRelationship
xdm:descriptorRelationship
xdm:descriptorRelationship
xdm:descriptorOneToOne
descriptors in standard schemas, continue using them unless you need features such as non-primary identity destination targets, custom naming, or expanded cardinality options.Capabilities comparison
The following table compares the capabilities of the two descriptor types:
xdm:descriptorOneToOne
xdm:descriptorRelationship
xdm:destinationProperty
xdm:sourceToDestinationName
, xdm:destinationToSourceName
, and titlesConstraints and validation
Follow these requirements and recommendations when defining a general relationship descriptor:
- For model-based schemas, place the source field (foreign key) at the root level. This is a current technical limitation for ingestion, not just a best-practice recommendation.
- Ensure that data types of source and destination fields are compatible (numeric, date, boolean, string).
- Remember that cardinality is informational; storage does not enforce it. Specify cardinality in
<source>:<destination>
format. Accepted values are:1:1
,1:0
,M:1
, orM:0
.
Primary key descriptor primary-key-descriptor
The primary key descriptor (xdm:descriptorPrimaryKey
) enforces uniqueness and non-null constraints on one or more fields in a schema.
{
"@type": "xdm:descriptorPrimaryKey",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": ["/orderId", "/orderLineId"]
}
@type
xdm:descriptorPrimaryKey
.xdm:sourceSchema
$id
URI of the schema.xdm:sourceProperty
Version descriptor version-descriptor
The version descriptor (xdm:descriptorVersion
) designates a field to detect and prevent conflicts from out-of-order change events.
{
"@type": "xdm:descriptorVersion",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": "/versionNumber"
}
@type
xdm:descriptorVersion
.xdm:sourceSchema
$id
URI of the schema.xdm:sourceProperty
required
.Timestamp descriptor timestamp-descriptor
The timestamp descriptor (xdm:descriptorTimestamp
) designates a date-time field as the timestamp for schemas with "meta:behaviorType": "time-series"
.
{
"@type": "xdm:descriptorTimestamp",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": "/eventTime"
}
@type
xdm:descriptorTimestamp
.xdm:sourceSchema
$id
URI of the schema.xdm:sourceProperty
required
and be of type date-time
.B2B relationship descriptor B2B-relationship-descriptor
The Real-Time CDP B2B Edition introduces an alternative way to define relationships between schemas, which allows for many-to-one relationships. This new relationship must have the @type: xdm:descriptorRelationship
type, and the payload must include more fields than the @type: xdm:descriptorOneToOne
relationship. See the tutorial on defining a schema relationship for B2B Edition for more information.
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema" : "https://ns.adobe.com/{TENANT_ID}/schemas/9f2b2f225ac642570a110d8fd70800ac0c0573d52974fa9a",
"xdm:sourceVersion" : 1,
"xdm:sourceProperty" : "/person-ref",
"xdm:destinationSchema" : "https://ns.adobe.com/{TENANT_ID/schemas/628427680e6b09f1f5a8f63ba302ee5ce12afba8de31acd7",
"xdm:destinationVersion" : 1,
"xdm:destinationProperty": "/personId",
"xdm:destinationNamespace" : "People",
"xdm:destinationToSourceTitle" : "Opportunity Roles",
"xdm:sourceToDestinationTitle" : "People",
"xdm:cardinality": "M:1"
}
@type
xdm:descriptorRelationship
. For information on additional types, see the relationship descriptors section.xdm:sourceSchema
$id
URI of the schema where the descriptor is being defined.xdm:sourceVersion
xdm:sourceProperty
xdm:destinationSchema
$id
URI of the reference schema this descriptor is defining a relationship with.xdm:destinationVersion
xdm:destinationProperty
xdm:sourceProperty
. If omitted, the relationship may not function as expected.xdm:destinationNamespace
xdm:destinationToSourceTitle
xdm:sourceToDestinationTitle
xdm:cardinality
M:1
, referring to a many-to-one relationship.Reference identity descriptor
Reference identity descriptors provide a reference context to the primary identity of a schema field, allowing it to be referenced by fields in other schemas. The reference schema must already have a primary identity field defined before it can be referred to by other schemas through this descriptor.
{
"@type": "xdm:descriptorReferenceIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/78bab6346b9c5102b60591e15e75d254",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/parentField/subField",
"xdm:identityNamespace": "Email"
}
@type
xdm:descriptorReferenceIdentity
.xdm:sourceSchema
$id
URI of the schema where the descriptor is being defined.xdm:sourceVersion
xdm:sourceProperty
/personalEmail/address
instead of /properties/personalEmail/properties/address
).xdm:identityNamespace
Deprecated field descriptor
You can deprecate a field within a custom XDM resource by adding a meta:status
attribute set to deprecated
to the field in question. If you want to deprecate fields provided by standard XDM resources in your schemas, however, you can assign a deprecated field descriptor to the schema in question to achieve the same effect. Using the correct Accept
header, you can then view which standard fields are deprecated for a schema when looking it up in the API.
{
"@type": "xdm:descriptorDeprecated",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/c65ddf08cf2d4a2fe94bd06113bf4bc4c855e12a936410d5",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/faxPhone"
}
@type
xdm:descriptorDeprecated
.xdm:sourceSchema
$id
of the schema you are applying the descriptor to.xdm:sourceVersion
1
.xdm:sourceProperty
["/firstName", "/lastName"]
).