Skip to main content

DSP Integration Guide

This guide is for DSPs who transact on UID2s in the bidstream.

DSPs receive UID2 tokens in bid requests, and decrypt the UID2 tokens to arrive at raw UID2s that they can use for bidding, using one of the server-side SDKs that support this function.

For a summary of available server-side SDKs, see SDKs: Summary.


If your back end is written in a language not covered by one of the available server-side SDKs, ask your UID2 contact in case there is additional information available to help you. If you're not sure who to ask, see Contact Info.

Integration Steps

The following describes the integration workflow for DSP to support UID2 as part of RTB, which consists of two major steps:

  1. Honor user opt-outs
  2. Decrypt UID2 tokens for RTB use

DSP Flow

Honor User Opt-Outs

This section includes the following information for DSPs, who must honor user opt-out of UID2:

Opt-Out Webhook

To receive and honor user opt-outs from the UID2 service, the DSP establishes a pre-configured interface (an opt-out webhook/API endpoint) and provides it to the UID2 service during onboarding. When a user opts out, the UID2 service sends the user's raw UID2 and the corresponding opt-out timestamp to the pre-configured interface.

The UID2 service sends the following data within seconds of a user's opt-out, which the DSP records and uses the bidding logic defined in Decrypt UID2 Tokens for RTB Use.

identityThe raw UID2 for the user who opted out.
timestampThe time when the user opted out (for information only).

The DSP must respond to the opt-out data with a 200 response code.

The following example illustrates a webhook configured to receive the raw UID2 and the corresponding timestamp:

POST /optout/status Endpoint

DSPs can check the opt-out status of raw UID2s using the POST /optout/status endpoint.

Bidding Opt-Out Logic

Use the logic below during bidding (2-b) to honor a user's opt-out.

Leverage one of the server-side SDKs (see SDKs: Summary) to decrypt incoming UID2 tokens into raw UID2s. The response to the decrypt function contains the raw UID2.

The following diagram illustrates opt-out logic.

DSP Opt-Out Check

If the user has opted out, the UID2 must not be used for RTB. In these cases, the DSP can choose to send an alternate ID for bidding or can choose not to bid.

Decrypt UID2 Tokens for RTB Use

The following table provides details for Step 2 of the workflow diagram shown in Integration Steps.

2-aServer-side SDK (see SDKs: Summary)Leverage the provided SDK to decrypt incoming UID2 tokens. The response contains the UID2 and the UID2 creation time.
2-bDSPs are required to honor opt-out protocol for UID2s. For details on configuring user opt-outs and honoring them during bidding, see Honor user opt-outs.

Recommendations for Managing Latency

For a low latency/high throughput setup, follow these recommendations:

  • Have a local instance of the UID2 client for each server. This can be in-process or out-of-process. In-process is easiest.
  • Call client refresh periodically in the background: for example, once per hour, with some randomization to avoid peaks after global fleet restarts.
  • When a token needs to be decrypted, call client decrypt. In-process is fastest, but out-of-process is also acceptable if it's done correctly.
  • Note that client decrypt is thread-safe. Therefore, you can call client decrypt on multiple threads at the same time.


For a list of frequently asked questions for DSPs, see FAQs for DSPs.