Overview

We recommend that you deploy ID5 in CTV environments via a server to server integration. We do support alternative integration pathways depending on your requirements. If required, please reach out to your ID5 customer services representative.

To ensure accurate identity resolution, clients should provide signals, such as hashed emails in the request. We also expect you to store the 'signature' provided in our response on the user's device and provision it to us in future requests for the same user. This is integral to an optimal set up since it helps us re-identify consenting users even if their signals change as well as respect opt out requests.

Below are general instructions on how to retrieve an ID5 ID server-side for CTV inventory and make it available in bid requests to your demand partners. The auction should be delayed in order to retrieve the user’s privacy preferences and the ID5 ID prior to sending out bid requests; the amount you delay may vary and so we recommend making it configurable for optimization purposes.

Process Flow

1. Check the stored cache for an available ID5 ID

   • IF there is no cached ID
     OR if the ID needs to be refreshed (we recommend a cache of 2 hours)
     OR if the user’s privacy preferences have changed:
     • Initialize a new HTTP POST request to the ID5 endpoint. If you previously had a stored response for a given user on their device, then subsequent requests must include the "signature" as part of the request to ID5;
     • Store the response from ID5 locally (either in local storage or in a database on the server);
   • ELSE if there is a valid, up-to-date value in cache:
     • Pull the latest ID5 ID response from the cache

2.  Using the response from step 1 above (from the request or cache), prepare the bid request data.

   • Extract the eid object(s) from the ids structure (e.g., from ids.id5id.eid for the ID5 Universal ID, and any additional enriched IDs if services like Real-Time Bid Enrichment are enabled).

3. Include this data in each bid request to your demand partners as an eids array in the user object. The EID structure is already formatted for direct use in OpenRTB bid requests. For more information on how this is typically done, including handling provenance fields for enriched IDs, review the OpenRTB EID Enrichment Guide.

Caching the response

The response we return for the request will need to be cached as some of the response data needs to be used in future requests for your users. Use the ts parameter sent in the request in order to set a TTL for the cache refresh and a TTL for the cache deletion.

• The TTL for the cache refresh should be set to 8 hours. After the 8 hours, on the back of a user event, a new request to ID5 should be made and the cached data refreshed using the data from the API response.
• The TTL for the cache deletion should be set to 30 days. The TTL for the cache deletion should be refreshed with every response from the API. If there will not be a user event in the app, in the 30 days time window, the data should be deleted.

Building Server-Side Request

Server-Side Fetch endpoints for CTV

Global

https://api.id5-sync.com/gc/v1

North America

https://na.id5-sync.com/gc/v1

Request Type

HTTP POST with JSON body.

Request Headers

Content-Type: application/json

Partner Number

The PARTNER in the request body will be an ID5-provided Partner Number. This value will be static for you once we set you up in our system. You may use the endpoint during testing with the Partner Number 173. If you haven't already been assigned a Partner Number, please contact us to request one.

Server-Side Request Parameters

Request Body

Identifier Object

Segment Object

Response Body

IDS Object

The ids objectprovides identifier data for the ID5 ID and any other Extended Identifiers (EIDs) received from ID5.

Each sub-object is named (e.g., id5id for the ID5 Universal ID) and contains an OpenRTB-compatible EID structure. Additional third-party identifiers may be included based on enabled services, such as Real-Time Bid Enrichment.

For example, the ids object might include:

• id5id: The ID5 Universal ID.
• euid: European Unified ID.
• id5-[provider]Other providers like PubMatic, Magnite, Xandr, TTD, etc.
  • For example: id5-ttd: The Trade Desk ID (enriched via ID5)

Each identifier contains an eid object that mirrors the structure of OpenRTB's eids field, enabling direct use in bid requests. For enriched IDs, provenance fields such as mm (match method), matcher, and inserter may be added to improve transparency and compliance with IAB best practices.

EID Object

UIDS Object

Privacy Object

ext Object

Invalid Request Response

Example Request

curl "https://api.id5-sync.com/gc/v1" -X POST -H 'Content-Type: application/json' -d '{
    "ts": "2023-09-19T12:32:34+02:00",
    "partner": 173,
    "ver": "1.0",
    "ip": "4.5.6.7",
    "ua": "Mozilla/5.0 (Linux; Android 11; moto e20 Build/RONS31.267-88-3; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/109.0.5414.118 Mobile Safari/537.36",
    "appid": "ABCDE12345.com.example.foo",
    "gpp_sid": "2",
    "gpp_string": "DBAA",
    "accept_language": "de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7",
    "identifiers": [{"id": "bfd378ed-483e-4b11-be1e-12a599d042e0", "type":"DPID"},{"id": "ID-12345", "type":"PPID"}]
}'
        

Example Valid Response

{
    "created_at": "2025-11-14T16:12:20.968Z",
    "original_uid": "ID5*KDdqfh7p46U_Eb_xD8-9lWYkX2xsHEQqpJP2YNzKqC7__",
    "privacy": {
        "id5_consent": true,
        "jurisdiction": "gdpr"
    },
    "signature": "ID5_AoPiwhPFUccYOQLCwfbQTEbMTk85rQD10hAZYixkNlZeozXos46w4uqpJqq",
    "universal_uid": "ID5*1Ls3HtzGAldqduMJjmL2CcyuGOw9JArVgXc_LS34MC7__",
    "ext": {
        "linkType": 2
    },
    "ids": {
        "id5id": {
            "eid": {
                "source": "id5-sync.com",
                "uids": [
                    {
                        "atype": 1,
                        "ext": {
                            "linkType": 2,
                            "pba": "Fhqkw5e7uf4ei8WEIXviXDGQnqqkVeEgVWijP20OAngDPxw=="
                        },
                        "id": "ID5*1Ls3HtzGAldqduMJjmL2CcyuGOw9JArVgXc_LS34MC7__"
                    }
                ]
            }
        },
        "euid": {
            "eid": {
                "source": "euid.eu",
                "uids": [
                    {
                        "atype": 3,
                        "ext": {
                            "provider": "id5-sync.com"
                        },
                        "id": "E4AAAAezwMkyH6T4wJwiMRLR7C7I77M2VyI8q_pQSzPLdIsfffl86arrL3FKC4T"
                    }
                ]
            }
        },
        "id5-ttd": {
            "eid": {
                "inserter": "publisher-domain.com",
                "matcher": "id5-sync.com",
                "mm": 2,
                "source": "adserver.org",
                "uids": [
                    {
                        "atype": 1,
                        "ext": {
                            "provider": "id5-sync.com",
                            "rtipartner": "TDID"
                        },
                        "id": "09d89c84-2e59-4c80-9c80-09db5f901234"
                    }
                ]
            }
        }
    }
}
        

Example Invalid Response

{
  "code": "partner_id_invalid",
  "message": "unknown partner",
  "type": "invalid_request_error"
}
        

ID5 Signature

The ID5 Signature will be returned on every response from ID5 and contains all "user state" information necessary to support cross-domain reconciliation. As an example, this could include the following pieces of data:

• Original UID value (an encrypted first party ID for this user on this domain/publisher)
• Cookie Birthdate
• Last Seen Timestamp (from this domain/publisher)
• Current ID5 ID value (encrypted)
• Link Type

The Signature is used only by ID5 (it will be encrypted with a private key) and must be passed in every subsequent request to ID5.