Reference Data Service

Current version: 10.2

The Reference Data Service is an XP service role that allows definition data to be stored and used within the xDB environment. Examples of data that can be stored in the Reference Data Service include:

  • Marketing Operations definitions, such as goals, outcomes, and automation plans

  • Browser agents

  • Site names

  • Airport codes

  • Loyalty scheme tier names

The Reference Data Service can be used by features such as interaction aggregation to look up additional information about referenced entities by way of a key. For example, an interaction aggregation processor might use an airport code from an interaction event to look up more information about that airport - such as its geographic location.

The following is true of all definition data:

  • The data originated from a non-xDB system, such as a Content Management server or a CRM.

  • A single definition can have data from multiple cultures.

  • The data is relatively static once it has been created - for example, renaming a goal would necessitate a reporting database rebuild.

Accessing the Reference Data Service

Use the Reference Data Client API to access the Reference Data Service. There are two interfaces available:

  • Sitecore.Xdb.ReferenceData.Core.IReadOnlyReferenceDataClient

  • Sitecore.Xdb.ReferenceData.Core.IReferenceDataClient

In both cases, the concrete implementation can either be an HTTP client or a service that accesses the Reference Data Service database directly:

  • Sitecore.Xdb.ReferenceData.Client.ReferenceDataHttpClient

  • Sitecore.Xdb.ReferenceData.Service.ReferenceDataService

Accessing Marketing Operations definitions

Do not use the Reference Data Client API to access marketing definitions such as goals, outcomes, and campaigns. Use the Marketing Operations API instead.


The Reference Data Service does not implement a locking mechanism, and there is no concurrency control. Each read operation and write operation is atomic, and the last successful write wins. This means that if you have two write operations that write to the same definition in a single batch, the second operation to complete will win and overwrite data from the first operation.

Do you have some feedback for us?

If you have suggestions for improving this article,