API Permissions
The UID2 ecosystem includes several different API permissions that allow access to complete specific activities. This approach is part of the overall secure design of UID2.
For each UID2 participant that has API Key and Client Secret, the permissions are linked to the participant's API credentials (see Account Setup and UID2 Credentials).
If you're a publisher and are implementing UID2 on the client side, API permissions do not apply to you. Instead, you'll receive a different set of credentials that are specifically for generating a client-side token request. For details, see Subscription ID and Public Key.
A participant can have one or several sets of API credentials with associated permissions. In cases where you have more than one API permission, you have the option to have a separate set of credentials for each permission or have a single set of credentials for all permissions. We recommend having a separate set of credentials for each permission.
The following table lists the key permissions, the types of participants that commonly use them, and a summary of the key associated activities.
Name | Participant Type | Permissions |
---|---|---|
Generator | Publishers | Permission to call the POST /token/generate, POST /token/validate, and POST /token/refresh endpoints, to generate UID2 tokens from DII and to refresh them, using one of these integration methods:
|
Bidder | DSPs | Permission to decrypt UID2 tokens coming in from the bidstream from publishers into raw UID2s for bidding purposes. |
Sharer | Any participant type that takes part in UID2 sharing. For details, see UID2 Sharing: Overview. | Permission to do both of the following:
|
Mapper | Advertisers Data Providers | Permission to use the POST /identity/buckets endpoint to monitor rotated salt buckets and to use the POST /identity/map endpoint to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s and salt bucket IDs. |