diff --git a/docs/endpoints/post-identity-buckets.md b/docs/endpoints/post-identity-buckets.md
index 866a60f7b..3b7644dd4 100644
--- a/docs/endpoints/post-identity-buckets.md
+++ b/docs/endpoints/post-identity-buckets.md
@@ -14,6 +14,12 @@ Monitors rotated salt bucke
Used by: This endpoint is used mainly by advertisers and data providers. For details, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
+:::important
+If you're using the latest version (v3) of `POST /v3/identity/map`, you don't need to use `POST /identity/buckets` at all. You only need to use it if you're using the earlier version (v2) of `POST /v2/identity/map`.
+
+If you're using the v2 version, we recommend that you upgrade as soon as possible, to take advantage of improvements. For migration guidance, see [Migration from v2 Identity Map](post-identity-map.md#migration-from-v2-identity-map).
+:::
+
## Request Format
`POST '{environment}/v2/identity/buckets'`
diff --git a/docs/endpoints/post-identity-map-v2.md b/docs/endpoints/post-identity-map-v2.md
new file mode 100644
index 000000000..0478a0b00
--- /dev/null
+++ b/docs/endpoints/post-identity-map-v2.md
@@ -0,0 +1,207 @@
+---
+title: POST /identity/map (v2)
+description: Maps DII to raw UID2s and salt bucket IDs.
+hide_table_of_contents: false
+sidebar_position: 07
+---
+
+import Link from '@docusaurus/Link';
+
+# POST /identity/map (v2)
+
+Maps multiple email addresses, phone numbers, or their respective hashes to their raw UID2s and salt bucket IDs. You can also use this endpoint to check for updates to opt-out information.
+
+Used by: This endpoint is used mainly by advertisers and data providers. For details, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
+
+For details about the UID2 opt-out workflow and how users can opt out, see [User Opt-Out](../getting-started/gs-opt-out.md).
+
+## Version
+
+This documentation is for version 2 of this endpoint, which is not the latest version. For the latest version, v3, see [POST /identity/map](post-identity-map.md).
+
+:::note
+If you're using the v2 version, we recommend that you upgrade as soon as possible, to take advantage of improvements. For migration guidance, see [Migration from v2 Identity Map](post-identity-map.md#migration-from-v2-identity-map).
+:::
+
+## Batch Size and Request Parallelization Requirements
+
+Here's what you need to know:
+
+- The maximum request size is 1MB.
+- To map a large number of email addresses, phone numbers, or their respective hashes, send them in *sequential* batches with a maximum batch size of 5,000 items per batch.
+- Unless you are using a Private Operator, do not send batches in parallel. In other words, use a single HTTP connection and send batches of hashed or unhashed directly identifying information (DII) values consecutively, without creating multiple parallel connections.
+- Be sure to store mappings of email addresses, phone numbers, or their respective hashes. Not storing mappings could increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of raw UID2s need to be updated daily. See also [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) and [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers).
+
+## Request Format
+
+`POST '{environment}/v2/identity/map'`
+
+For authentication details, see [Authentication and Authorization](../getting-started/gs-auth.md).
+
+:::important
+You must encrypt all requests using your secret. For details, and code examples in different programming languages, see [Encrypting Requests and Decrypting Responses](../getting-started/gs-encryption-decryption.md).
+:::
+
+### Path Parameters
+
+| Path Parameter | Data Type | Attribute | Description |
+| :--- | :--- | :--- | :--- |
+| `{environment}` | string | Required | Testing (integration) environment: `https://operator-integ.uidapi.com` Production environment: The best choice depends on where your users are based. For information about how to choose the best URL for your use case, and a full list of valid base URLs, see [Environments](../getting-started/gs-environments.md). |
+
+:::note
+The integration environment and the production environment require different API keys. For information about getting credentials for each environment, see [Getting Your Credentials](../getting-started/gs-credentials.md#getting-your-credentials).
+:::
+
+### Unencrypted JSON Body Parameters
+
+:::important
+You must include only **one** of the following four conditional parameters as a key-value pair in the JSON body of the request when encrypting it.
+:::
+
+| Body Parameter | Data Type | Attribute | Description |
+| :--- | :--- | :--- | :--- |
+| `email` | string array | Conditionally Required | The list of email addresses to be mapped. |
+| `email_hash` | string array | Conditionally Required | The list of [Base64-encoded SHA-256](../getting-started/gs-normalization-encoding.md#email-address-hash-encoding) hashes of [normalized](../getting-started/gs-normalization-encoding.md#email-address-normalization) email addresses to be mapped. |
+| `phone` | string array | Conditionally Required | The list of [normalized](../getting-started/gs-normalization-encoding.md#phone-number-normalization) phone numbers to be mapped. |
+| `phone_hash` | string array | Conditionally Required | The list of [Base64-encoded SHA-256](../getting-started/gs-normalization-encoding.md#phone-number-hash-encoding) hashes of [normalized](../getting-started/gs-normalization-encoding.md#phone-number-normalization) phone numbers to be mapped. |
+
+### Request Examples
+
+The following are unencrypted JSON request body examples for each parameter, one of which you should include in your requests to the `POST /identity/map` endpoint:
+
+```json
+{
+ "email":[
+ "user@example.com",
+ "user2@example.com"
+ ]
+}
+```
+```json
+{
+ "email_hash":[
+ "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
+ "KzsrnOhCq4tqbGFMsflgS7ig1QLRr0nFJrcrEIlOlbU="
+ ]
+}
+```
+```json
+{
+ "phone":[
+ "+12345678901",
+ "+441234567890"
+ ]
+}
+```
+```json
+{
+ "phone_hash":[
+ "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ="
+ ]
+}
+```
+
+Here's an encrypted request example to the `POST /identity/map` endpoint for a phone number:
+
+```sh
+echo '{"phone": ["+12345678901", "+441234567890"]}' | python3 uid2_request.py https://prod.uidapi.com/v2/identity/map [Your-Client-API-Key] [Your-Client-Secret]
+```
+
+For details, and code examples in different programming languages, see [Encrypting Requests and Decrypting Responses](../getting-started/gs-encryption-decryption.md).
+
+## Decrypted JSON Response Format
+
+:::note
+The response is encrypted only if the HTTP status code is 200. Otherwise, the response is not encrypted.
+:::
+
+A successful decrypted response returns the raw UID2s and salt bucket IDs for the specified email addresses, phone numbers, or their respective hashes.
+
+```json
+{
+ "body":{
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ },
+ {
+ "identifier": "Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ=",
+ "advertising_id": "IbW4n6LIvtDj/8fCESlU0QG9K/fH63UdcTkJpAG8fIQ=",
+ "bucket_id": "ad1ANEmVZ"
+ }
+ ]
+ },
+ "status":"success"
+}
+```
+
+If some identifiers are considered invalid, they are included in the response in an "unmapped" list. In this case, the response status is still "success". If all identifiers are mapped, the "unmapped" list is not included in the response.
+
+```json
+{
+ "body":{
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ }
+ ],
+ "unmapped": [
+ {
+ "identifier": "some@malformed@email@hash",
+ "reason": "invalid identifier"
+ }
+ ]
+ },
+ "status":"success"
+}
+```
+
+If some identifiers have opted out from the UID2 ecosystem, the opted-out identifiers are moved to the "unmapped" list along with any invalid identifiers found. In this case, the response status is still "success".
+
+```json
+{
+ "body":{
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ }
+ ],
+ "unmapped": [
+ {
+ "identifier": "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
+ "reason": "optout"
+ }
+ ]
+ },
+ "status":"success"
+}
+```
+
+### Response Body Properties
+
+The response body includes the properties shown in the following table.
+
+| Property | Data Type | Description |
+| :--- | :--- | :--- |
+| `identifier` | string | The email address, phone number, or respective hash specified in the request body. |
+| `advertising_id` | string | The corresponding advertising ID (raw UID2). |
+| `bucket_id` | string | The ID of the salt bucket used to generate the raw UID2. |
+
+### Response Status Codes
+
+The following table lists the `status` property values and their HTTP status code equivalents.
+
+| Status | HTTP Status Code | Description |
+| :--- | :--- | :--- |
+| `success` | 200 | The request was successful. The response will be encrypted. |
+| `client_error` | 400 | The request had missing or invalid parameters.|
+| `unauthorized` | 401 | The request did not include a bearer token, included an invalid bearer token, or included a bearer token unauthorized to perform the requested operation. |
+
+If the `status` value is anything other than `success`, the `message` field provides additional information about the issue.
diff --git a/docs/endpoints/post-identity-map.md b/docs/endpoints/post-identity-map.md
index e415df5c7..d292def72 100644
--- a/docs/endpoints/post-identity-map.md
+++ b/docs/endpoints/post-identity-map.md
@@ -1,21 +1,27 @@
---
title: POST /identity/map
-description: Maps DII to raw UID2s and salt bucket IDs.
+description: Maps DII to raw UID2s.
hide_table_of_contents: false
sidebar_position: 08
-displayed_sidebar: docs
+displayed_sidebar: docs
---
import Link from '@docusaurus/Link';
# POST /identity/map
-Maps multiple email addresses, phone numbers, or their respective hashes to their raw UID2s and salt bucket IDs. You can also use this endpoint to check for updates to opt-out information.
+Maps multiple email addresses, phone numbers, or their respective hashes to their raw UID2s. You can also use this endpoint to check for updates to opt-out information, check when a raw UID2 can be refreshed, or view the previous UID2 if the current UID2 is less than 90 days old.
Used by: This endpoint is used mainly by advertisers and data providers. For details, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
For details about the UID2 opt-out workflow and how users can opt out, see [User Opt-Out](../getting-started/gs-opt-out.md).
+## Version
+
+This documentation is for the latest version of this endpoint, version 3.
+
+If needed, documentation is also available for the previous version: see [POST /identity/map (v2)](post-identity-map-v2.md).
+
## Batch Size and Request Parallelization Requirements
Here's what you need to know:
@@ -23,11 +29,11 @@ Here's what you need to know:
- The maximum request size is 1MB.
- To map a large number of email addresses, phone numbers, or their respective hashes, send them in *sequential* batches with a maximum batch size of 5,000 items per batch.
- Unless you are using a Private Operator, do not send batches in parallel. In other words, use a single HTTP connection and send batches of hashed or unhashed directly identifying information (DII) values consecutively, without creating multiple parallel connections.
-- Be sure to store mappings of email addresses, phone numbers, or their respective hashes. Not storing mappings could increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of raw UID2s need to be updated daily. See also [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) and [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers).
+- Be sure to store mappings of email addresses, phone numbers, or their respective hashes. Not storing mappings could increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of UID2s need to be updated daily. See also [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) and [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers).
## Request Format
-`POST '{environment}/v2/identity/map'`
+`POST '{environment}/v3/identity/map'`
For authentication details, see [Authentication and Authorization](../getting-started/gs-auth.md).
@@ -48,46 +54,40 @@ The integration environment and the production environment require different
If the current raw UID2 has been rotated in the last 90 days: the previous value.
If the current raw UID2 is older than 90 days: `null`.
|
+| `r` | number | The Unix timestamp (in milliseconds) that indicates when the raw UID2 might be refreshed. The raw UID2 is guaranteed to be valid until this timestamp. |
+
+For unsuccessfully mapped input values, the mapped object includes the properties shown in the following table.
+
+| Property | Data Type | Description |
+|:---------|:----------|:-----------------------------------------------------------------------------------------------------------------|
+| `e` | string | The reason for being unable to map the DII to a raw UID2. One of two possible values:
`optout`
`invalid identifier`
|
### Response Status Codes
@@ -194,7 +190,116 @@ The following table lists the `status` property values and their HTTP status cod
| Status | HTTP Status Code | Description |
| :--- | :--- | :--- |
| `success` | 200 | The request was successful. The response will be encrypted. |
-| `client_error` | 400 | The request had missing or invalid parameters.|
+| `client_error` | 400 | The request had missing or invalid parameters. |
| `unauthorized` | 401 | The request did not include a bearer token, included an invalid bearer token, or included a bearer token unauthorized to perform the requested operation. |
If the `status` value is anything other than `success`, the `message` field provides additional information about the issue.
+
+## Migration from v2 Identity Map
+
+The following sections provide general information and guidance for migrating to version 3 from earlier versions, including:
+
+- [Version 3 Improvements](#version-3-improvements)
+- [Key Differences Between v2 and v3](#key-differences-between-v2-and-v3)
+- [Required Changes](#required-changes)
+- [Additional Resources](#additional-resources)
+
+### Version 3 Improvements
+
+The v3 Identity Map API provides the following improvements over v2:
+
+- **Simplified Refresh Management**: You can monitor for UID2s reaching `refresh_from` timestamps instead of polling salt buckets for rotation.
+- **Previous UID2 Access**: You have access to previous raw UID2s for 90 days after rotation for campaign measurement.
+- **Single Endpoint**: You use only one endpoint, `/v3/identity/map`, instead of both `/v2/identity/map` and `/v2/identity/buckets`.
+- **Multiple Identity Types in One Request**: You can process both emails and phone numbers in a single request.
+- **Improved Performance**: The updated version uses significantly less bandwidth to process the same amount of DII.
+
+### Key Differences Between v2 and v3
+
+The following table shows key differences between the versions.
+
+| Feature | V2 Implementation | V3 Implementation |
+|:-------------------------------|:--------------------------------------------|:-------------------------------------------|
+| Endpoints Required | `/v2/identity/map` + `/v2/identity/buckets` | `/v3/identity/map` only |
+| Identity Types per Request | Single identity type only | Multiple identity types |
+| Refresh Management | Monitor salt bucket rotations via `/identity/buckets` endpoint | Re-map when past `refresh_from` timestamps |
+| Previous UID2 Access | Not available | Available for 90 days |
+
+### Required Changes
+
+To upgrade from an earlier version to version 3, follow these steps:
+
+1. [Update Endpoint URL](#1-update-endpoint-url)
+2. [Update V3 Response Parsing Logic](#2-update-v3-response-parsing-logic)
+3. [Replace Salt Bucket Monitoring with Refresh Timestamp Logic](#3-replace-salt-bucket-monitoring-with-refresh-timestamp-logic)
+
+#### 1. Update Endpoint URL
+
+Update any reference to the endpoint URL so that it references the /v3/ implementation, as shown in the following example.
+
+```python
+# Before (v2)
+url = '/v2/identity/map'
+
+# After (v3)
+url = '/v3/identity/map'
+```
+
+#### 2. Update v3 Response Parsing Logic
+
+Update the logic for parsing the response, as shown in the following example.
+
+V2 Response Parsing:
+```python
+# v2: Process mapped/unmapped objects with identifier lookup
+for item in response['body']['mapped']:
+ raw_uid = item['advertising_id']
+ bucket_id = item['bucket_id']
+ original_identifier = item['identifier']
+ # Store mapping using identifier as key
+ store_mapping(original_identifier, raw_uid, bucket_id)
+```
+
+V3 Response Parsing:
+```python
+# v3: Process array-indexed responses
+for index, item in enumerate(response['body']['email']):
+ original_email = request_emails[index] # Use array index to correlate
+ if 'u' in item:
+ # Successfully mapped
+ current_uid = item['u']
+ previous_uid = item.get('p') # Available for 90 days after rotation, otherwise None
+ refresh_from = item['r']
+ store_mapping(original_email, current_uid, previous_uid, refresh_from)
+ elif 'e' in item:
+ # Handle unmapped with reason
+ handle_unmapped(original_email, item['e'])
+```
+
+#### 3. Replace Salt Bucket Monitoring with Refresh Timestamp Logic
+
+Update your code for salt bucket monitoring, replacing it with code that checks the `refresh_from` timestamp to determine raw UID2s that are due for refresh.
+
+The following example shows an implementation of the v3 approach for checking refresh timestamps:
+
+```python
+import time
+
+def is_refresh_needed(mapping):
+ now = int(time.time() * 1000) # Convert to milliseconds
+ return now >= mapping['refresh_from']
+
+# Check individual mappings for refresh needs
+to_remap = [mapping for mapping in mappings if is_refresh_needed(mapping)]
+remap_identities(to_remap)
+```
+
+### Additional Resources
+- [SDK for Java](../sdks/sdk-ref-java.md) for Java implementations (see Usage for Advertisers/Data Providers section)
+
+
+
+
+
+For general information about identity mapping, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
diff --git a/docs/endpoints/summary-endpoints.md b/docs/endpoints/summary-endpoints.md
index b9ef57d8a..cd865d094 100644
--- a/docs/endpoints/summary-endpoints.md
+++ b/docs/endpoints/summary-endpoints.md
@@ -22,14 +22,32 @@ The following endpoints are for retrieving and managing UID2 tokens (identity to
| [POST /token/validate](post-token-validate.md) | Used for testing, to validate that an advertising token (UID2) matches the specified email address, phone number, or the respective hash. | Required | Required |
| [POST /token/refresh](post-token-refresh.md) | Generates a new token for a user for their refresh token from the [POST /token/generate](post-token-generate.md) response. | N/A | Required |
-## Identity Maps
+## Identity Map
The following endpoints are used by advertisers and third-party data providers. Publishers do not need to use these endpoints.
+### Latest Identity Map Endpoint (v3)
+
+In the latest identity map integration, you only need to call one endpoint, `POST /identity/map`. The `POST /identity/buckets` endpoint is not part of the workflow.
+
+:::important
+If you're using the earlier version, we recommend that you upgrade as soon as possible, to take advantage of improvements.
+:::
+
+The latest identity map integration uses the following endpoint:
+
+| Endpoint | Description | Request Encryption | Response Decryption |
+| :--- | :--- | :--- | :--- |
+| [POST /identity/map](post-identity-map.md) | Maps raw UID2s, previous raw UID2s, and refresh timestamps for one or more email addresses, phone numbers, or their respective hashes. | Required | Required |
+
+### Earlier Identity Map Endpoints (v2)
+
+The following endpoints are part of the earlier identity map integration (version 2).
+
| Endpoint | Description | Request Encryption | Response Decryption |
| :--- | :--- | :--- | :--- |
| [POST /identity/buckets](post-identity-buckets.md) | Monitors rotated salt buckets using their last updated timestamp. | Required | Required |
-| [POST /identity/map](post-identity-map.md) | Retrieves raw UID2s and salt bucket IDs for one or more email addresses, phone numbers, or their respective hashes. | Required | Required |
+| [POST /identity/map (v2)](post-identity-map-v2.md) | Maps raw UID2s and salt bucket IDs for one or more email addresses, phone numbers, or their respective hashes. | Required | Required |
## Opt-Out Status
@@ -39,4 +57,4 @@ For details about the UID2 opt-out workflow and how users can opt out, see [User
| Endpoint | Description | Request Encryption | Response Decryption |
| :--- | :--- | :--- | :--- |
-| [POST /optout/status](post-optout-status.md) | Checks the opt-out status of raw UID2s. This endpoint takes a list of raw UID2s as input, and returns the raw UID2s that have opted out, as well as the time that the opt-out took place. | Required | Required |
+| [POST /optout/status](post-optout-status.md) | Checks the opt-out status of UID2s. This endpoint takes a list of UID2s as input, and returns the UID2s that have opted out, as well as the time that the opt-out took place. | Required | Required |
diff --git a/docs/getting-started/gs-faqs.md b/docs/getting-started/gs-faqs.md
index 16b1c67b5..c97c45642 100644
--- a/docs/getting-started/gs-faqs.md
+++ b/docs/getting-started/gs-faqs.md
@@ -167,36 +167,38 @@ For details, see [Publisher Integration with SSO Providers](/docs/ref-info/ref-i
Here are some frequently asked questions for advertisers and data providers using the UID2 framework.
-- [How do I know when to refresh the UID2 due to salt bucket rotation?](#how-do-i-know-when-to-refresh-the-uid2-due-to-salt-bucket-rotation)
-- [Do refreshed emails get assigned to the same bucket with which they were previously associated?](#do-refreshed-emails-get-assigned-to-the-same-bucket-with-which-they-were-previously-associated)
-- [How often should UID2s be refreshed for incremental updates?](#how-often-should-uid2s-be-refreshed-for-incremental-updates)
+- [How do I know when to refresh a raw UID2?](#how-do-i-know-when-to-refresh-a-raw-uid2)
+- [How often should raw UID2s be refreshed for incremental updates?](#how-often-should-raw-uid2s-be-refreshed-for-incremental-updates)
- [How should I generate the SHA-256 of DII for mapping?](#how-should-i-generate-the-sha-256-of-dii-for-mapping)
- [Should I store mapping of email addresses, phone numbers, or corresponding hashes to raw UID2s in my own datasets?](#should-i-store-mapping-of-email-addresses-phone-numbers-or-corresponding-hashes-to-raw-uid2s-in-my-own-datasets)
- [How should I handle user opt-outs?](#how-should-i-handle-user-opt-outs)
- [Does the same DII always result in the same raw UID2?](#does-the-same-dii-always-result-in-the-same-raw-uid2)
- [If two operators process the same DII, are the results the same?](#if-two-operators-process-the-same-dii-are-the-results-the-same)
+- [How do I know when to refresh the UID2 due to salt bucket rotation?](#how-do-i-know-when-to-refresh-the-uid2-due-to-salt-bucket-rotation)
+- [Do refreshed emails get assigned to the same bucket with which they were previously associated?](#do-refreshed-emails-get-assigned-to-the-same-bucket-with-which-they-were-previously-associated)
-#### How do I know when to refresh the UID2 due to salt bucket rotation?
-
-Metadata supplied with the UID2 generation request indicates the salt bucket used for generating the UID2. Salt buckets persist and correspond to the underlying DII used to generate a UID2. Use the [POST /identity/buckets](../endpoints/post-identity-buckets.md) endpoint to return which salt buckets rotated since a given timestamp. The returned rotated salt buckets inform you which UID2s to refresh.
+#### How do I know when to refresh a raw UID2?
-:::note
-We do not make any promises about when the rotation takes place. To stay as up-to-date as possible, we recommend doing the checks once per hour.
-:::
+The [POST /identity/map](../endpoints/post-identity-map.md) endpoint provides a refresh timestamp in the response (`r` field) that indicates a timestamp, after which each raw UID2 might refresh. Use this timestamp to determine when to regenerate raw UID2s for your stored data.
-#### Do refreshed emails get assigned to the same bucket with which they were previously associated?
+To determine whether to refresh a raw UID2:
-Not necessarily. After you remap emails associated with a particular bucket ID, the emails might be assigned to a different bucket ID. To check the bucket ID, see [Generate Raw UID2s from DII](../guides/integration-advertiser-dataprovider-overview.md#1-generate-raw-uid2s-from-dii) and save the returned raw UID2 and bucket ID again.
+1. Compare the current time with the refresh timestamp you stored from the [POST /identity/map](../endpoints/post-identity-map.md) response.
+2. If the current time is greater than or equal to the refresh timestamp, regenerate the raw UID2 by calling the identity map endpoint again with the same DII.
-:::info
-When mapping and remapping emails, do not make any assumptions about the number of buckets, their rotation dates, or the specific bucket that an email gets assigned to.
+:::note
+We recommend checking for refresh opportunities daily. It is guaranteed that the raw UID2 won't refresh before the indicated timestamp. At some point on or after that time, the raw UID2 is refreshed.
:::
-#### How often should UID2s be refreshed for incremental updates?
+#### How often should raw UID2s be refreshed for incremental updates?
The recommended cadence for updating audiences is daily.
-Even though each salt bucket is updated roughly once a year, individual bucket updates are spread over the year. This means that about 1/365th of all buckets are rotated daily. If fidelity is critical, consider calling the [POST /identity/buckets](../endpoints/post-identity-buckets.md) endpoint more frequently; for example, hourly.
+A raw UID2 for a specific user changes roughly once per year. The latest version of the [POST /identity/map](../endpoints/post-identity-map.md) endpoint provides refresh timestamps that indicate a point after which each raw UID2 might refresh. We recommend checking these timestamps daily to ensure your raw UID2s remain current and valid for audience targeting.
+
+For implementations that reference earlier versions of this endpoint (see [POST /identity/map v2](../endpoints/post-identity-map-v2.md)):
+
+Even though each salt bucket is updated roughly once a year, individual bucket updates are spread over the year. This means that about 1/365th of all buckets are rotated daily. If fidelity is critical, consider calling the [POST /identity/buckets](../endpoints/post-identity-buckets.md) endpoint more frequently; for example, hourly.
#### How should I generate the SHA-256 of DII for mapping?
@@ -204,7 +206,7 @@ The system should follow the [email normalization rules](gs-normalization-encodi
#### Should I store mapping of email addresses, phone numbers, or corresponding hashes to raw UID2s in my own datasets?
-Yes. Not storing mappings may increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of UID2s need to be updated daily.
+Yes. Not storing mappings might increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of raw UID2s need to be updated daily.
:::important
Unless you are using a Private Operator, you must map email addresses, phone numbers, or hashes consecutively, using a single HTTP connection, with a maximum batch size of 5,000 items per batch. In other words, do your mapping without creating multiple parallel connections.
@@ -212,7 +214,7 @@ Unless you are using a salt value that's used in generating the raw UID2. The salt values are rotated roughly once per year (for details, see [How often should UID2s be refreshed for incremental updates?](#how-often-should-uid2s-be-refreshed-for-incremental-updates)). If the salt value changes between one request and another, those two requests result in two different raw UID2, even when the DII is the same.
+However, there is a variable factor that's used in generating the raw UID2. The underlying values are refreshed roughly once per year (for details, see [How often should raw UID2s be refreshed for incremental updates?](#how-often-should-raw-uid2s-be-refreshed-for-incremental-updates)). If these values change between one request and another, those two requests result in two different raw UID2, even when the DII is the same.
-For more information, see [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](../guides/integration-advertiser-dataprovider-overview.md#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s) in the *Advertiser/Data Provider Integration Guide*.
+For more information, see [Monitor for Raw UID2 Refresh](../guides/integration-advertiser-dataprovider-overview.md#5-monitor-for-raw-uid2-refresh) in the *Advertiser/Data Provider Integration Guide*.
#### If two operators process the same DII, are the results the same?
@@ -232,10 +234,26 @@ Yes, if the request is for a r
The result is the same, regardless of the Operator and whether it's a Private Operator or a Public Operator.
-The timing is important only because of salt bucket rotation. If the salt value changes between one request and another, the result is a different raw UID2.
+The timing is important only because of refresh cycles. If the underlying values change between one request and another, the result is a different raw UID2.
However, if a publisher sends DII in a request for a UID2 token, via the [POST /token/generate](../endpoints/post-token-generate.md) or [POST /token/refresh](../endpoints/post-token-refresh.md) endpoint or via an SDK, the resulting UID2 token contains the same encrypted raw UID2, but the token itself is always unique.
+#### How do I know when to refresh the UID2 due to salt bucket rotation?
+
+Metadata supplied with the UID2 generation request indicates the salt bucket used for generating the UID2. Salt buckets persist and correspond to the underlying DII used to generate a UID2. Use the [POST /identity/buckets](../endpoints/post-identity-buckets.md) endpoint to return which salt buckets rotated since a given timestamp. The returned rotated salt buckets inform you which UID2s to refresh.
+
+:::note
+We do not make any promises about when the rotation takes place. To stay as up-to-date as possible, we recommend doing the checks once per hour.
+:::
+
+#### Do refreshed emails get assigned to the same bucket with which they were previously associated?
+
+Not necessarily. After you remap emails associated with a particular bucket ID, the emails might be assigned to a different bucket ID. To check the bucket ID, see [Generate Raw UID2s from DII](../guides/integration-advertiser-dataprovider-overview.md#1-generate-raw-uid2s-from-dii) and save the returned raw UID2 and bucket ID again.
+
+:::info
+When mapping and remapping emails, do not make any assumptions about the number of buckets, their rotation dates, or the specific bucket that an email gets assigned to.
+:::
+
## FAQs for DSPs
Here are some frequently asked questions for demand-side platforms (DSPs).
@@ -243,7 +261,7 @@ Here are some frequently asked questions for demand-side platforms (DSPs).
- [How do I know which decryption key to apply to a UID2?](#how-do-i-know-which-decryption-key-to-apply-to-a-uid2)
- [Where do I get the decryption keys?](#where-do-i-get-the-decryption-keys)
- [How many decryption keys may be present in memory at any point?](#how-many-decryption-keys-may-be-present-in-memory-at-any-point)
-- [How do I know if/when the salt bucket has rotated?](#how-do-i-know-ifwhen-the-salt-bucket-has-rotated)
+- [How do I know when to refresh mapped raw UID2s?](#how-do-i-know-when-to-refresh-mapped-raw-uid2s)
- [Should the DSP be concerned with latency?](#should-the-dsp-be-concerned-with-latency)
- [How should the DSP maintain proper frequency capping with UID2?](#how-should-the-dsp-maintain-proper-frequency-capping-with-uid2)
- [Will all user opt-out traffic be sent to the DSP?](#will-all-user-opt-out-traffic-be-sent-to-the-dsp)
@@ -268,9 +286,13 @@ You can use one of the server-side SDKs (see [SDKs: Summary](../sdks/summary-sdk
There may be thousands of decryption keys present in the system at any given point.
-#### How do I know if/when the salt bucket has rotated?
+#### How do I know when to refresh mapped raw UID2s?
+
+See [Advertisers and Data Providers section](#how-do-i-know-when-to-refresh-a-raw-uid2).
+
+#### How do I know if/when the raw UID2 has rotated?
-The DSP is not privy to when the UID2 salt bucket rotates. This is similar to a DSP being unaware if users cleared their cookies. Salt bucket rotation has no significant impact on the DSP.
+The DSP is not privy to when the raw UID2 rotates. This is similar to a DSP being unaware if users cleared their cookies. Raw UID2 rotation has no significant impact on the DSP.
#### Should the DSP be concerned with latency?
@@ -278,7 +300,7 @@ The UID2 service does not introduce latency into the bidding process. Any latenc
#### How should the DSP maintain proper frequency capping with UID2?
-The UID2 has the same chance as a cookie of becoming stale. Hence, the DSP can adapt the same infrastructure currently used for cookie or deviceID-based frequency capping for UID2. For details, see [How do I know when to refresh the UID2 due to salt bucket rotation?](#how-do-i-know-when-to-refresh-the-uid2-due-to-salt-bucket-rotation).
+The UID2 has the same chance as a cookie of becoming stale. Hence, the DSP can adapt the same infrastructure currently used for cookie or deviceID-based frequency capping for UID2. For details, see [How do I know when to refresh a raw UID2?](#how-do-i-know-when-to-refresh-a-raw-uid2).
#### Will all user opt-out traffic be sent to the DSP?
diff --git a/docs/getting-started/gs-opt-out.md b/docs/getting-started/gs-opt-out.md
index fe13493b7..5be66a84c 100644
--- a/docs/getting-started/gs-opt-out.md
+++ b/docs/getting-started/gs-opt-out.md
@@ -20,7 +20,7 @@ Within the UID2 ecosystem, there are two types of opt out:
Because each participant has their own opt-out workflow, participants are mandated to respect a user's opted-out status and therefore not create a UID2 for any user who opted out from the participant.
-For example, if a user opts out of a publisher's site, but has not opted out of UID2, the publisher should not generate a UID2 token for that user.
+For example, if a user opts out of a publisher's site, but has not opted out of UID2, the publisher should not generate a UID2 token for that user.
Consumers can always opt out of UID2 being used to show them personalized ads, in the [Transparency and Control Portal](https://www.transparentadvertising.com/). Choose email address or phone number, enter the data, and follow the prompts.
@@ -48,7 +48,7 @@ The following steps provide a high-level outline of the opt-out workflow intende
| Participant | Distribution Method |
| :--- | :--- |
- | Publishers | A publisher calling [POST /token/generate](../endpoints/post-token-generate.md) with the required `optout_check` parameter set to `1`, or [POST /token/refresh](../endpoints/post-token-refresh.md), receives the opt-out response instead of the UID2 token. |
+ | Publishers | A publisher calling [POST /token/generate](../endpoints/post-token-generate.md) with the required `optout_check` parameter set to `1`, or [POST /token/refresh](../endpoints/post-token-refresh.md), receives the opt-out response instead of the UID2 token. |
| DSPs | The UID2 Operator Service distributes information on all opted-out users to DSPs via a webhook provided for the purpose. For details, see [Honor User Opt-Outs](../guides/dsp-guide#honor-user-opt-outs). DSPs can also check the opt-out status of raw UID2s using the [POST /optout/status](../endpoints/post-optout-status.md) endpoint. |
| Advertisers and data providers | The UID2 Operator Service distributes opt-out information to advertisers and data providers via the [POST /identity/map](../endpoints/post-identity-map.md) endpoint. Another option is to check the opt-out status of raw UID2s using the [POST /optout/status](../endpoints/post-optout-status.md) endpoint. |
| Sharers | UID2 sharers can check the opt-out status of raw UID2s using the [POST /optout/status](../endpoints/post-optout-status.md) endpoint. |
diff --git a/docs/getting-started/gs-permissions.md b/docs/getting-started/gs-permissions.md
index 1a62e37a6..fdaa9d9a8 100644
--- a/docs/getting-started/gs-permissions.md
+++ b/docs/getting-started/gs-permissions.md
@@ -18,7 +18,7 @@ For each UID2 participant that has API Key and Client Secret, the permissions ar
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](gs-credentials.md#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.
+A participant can have one or several sets of API credentials with associated permissions. In cases where you have m ore 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.
@@ -27,4 +27,4 @@ The following table lists the key permissions, the types of participants that co
| Generator | Publishers | Permission to call the [POST /token/generate](../endpoints/post-token-generate.md), [POST /token/validate](../endpoints/post-token-validate.md), and [POST /token/refresh](../endpoints/post-token-refresh.md) endpoints, to generate UID2 tokens from DII and to refresh them, using one of these integration methods:
A Prebid integration
The SDK for JavaScript
An integration that directly calls the applicable API endpoints for retrieving and managing UID2 tokens.
|
| 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](../sharing/sharing-overview.md). | Permission to do both of the following:
Encrypt raw UID2s into UID2 tokens for sharing with another authorized sharing participant, using a UID2 SDK or Snowflake
Decrypt UID2 tokens received from another authorized sharing participant into raw UID2s.
|
-| Mapper | Advertisers Data Providers | Permission to use the [POST /identity/buckets](../endpoints/post-identity-buckets.md) endpoint to monitor rotated salt buckets and to use the [POST /identity/map](../endpoints/post-identity-map.md) endpoint to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s and salt bucket IDs. |
+| Mapper | Advertisers Data Providers | Permission to call the following endpoints to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s, previous raw UID2s, and refresh timestamps:
The earlier v2 identity mapping endpoints: [POST /identity/map (v2)](../endpoints/post-identity-map.md) and [POST /identity/buckets](../endpoints/post-identity-buckets.md).
|
diff --git a/docs/guides/images/advertiser-flow-endpoints-mermaid-v3.png b/docs/guides/images/advertiser-flow-endpoints-mermaid-v3.png
new file mode 100644
index 000000000..4e6dd74f8
Binary files /dev/null and b/docs/guides/images/advertiser-flow-endpoints-mermaid-v3.png differ
diff --git a/docs/guides/images/advertiser-flow-overview-mermaid-v3.png b/docs/guides/images/advertiser-flow-overview-mermaid-v3.png
new file mode 100644
index 000000000..840bff733
Binary files /dev/null and b/docs/guides/images/advertiser-flow-overview-mermaid-v3.png differ
diff --git a/docs/guides/images/resource/advertiser-flow-endpoints-mermaid.md.bak b/docs/guides/images/resource/advertiser-flow-endpoints-v2-mermaid.md.bak
similarity index 99%
rename from docs/guides/images/resource/advertiser-flow-endpoints-mermaid.md.bak
rename to docs/guides/images/resource/advertiser-flow-endpoints-v2-mermaid.md.bak
index 6223664e3..d26caabf0 100644
--- a/docs/guides/images/resource/advertiser-flow-endpoints-mermaid.md.bak
+++ b/docs/guides/images/resource/advertiser-flow-endpoints-v2-mermaid.md.bak
@@ -1,4 +1,4 @@
->DSP: Send stored raw UID2s to DSPs to create audiences and conversions, or use them for measurement.
+ Note over ADP,DSP: 5. Monitor for raw UID2 refresh.
+ loop
+ ADP->>ADP: 5-a. Check current time against stored refresh timestamps.
+ ADP->>UID: 5-b. If refresh time reached, resend DII to the POST /identity/map endpoint for updated raw UID2.
+ UID->>ADP: 5-c. Store the new raw UID2 (u), refresh timestamp (r), and optionally previous UID2 (p) returned from the POST /identity/map endpoint.
+ end
+ Note over ADP,DSP: 6. Monitor for opt-out status. Remove all opt-outs from local storage and do not use.
+ loop
+ ADP->>UID: 6-a. Monitor for optout status using the POST /optout/status endpoint.
+ UID->>ADP: 6-b. Return optout status.
+ end
+
+%%URL:
+%%https://mermaid.live/edit#pako:eNrNVU1v2kAQ_SujPSUSGDDYgA-RolBVHNKg0F4qLht7gFXxrrsfSWmU_97ZNeYjASnH-oDZ3Zk3b948rV9ZrgpkGQMw-NuhzHEi-ErzciGBnoprK3JRcWnhdjIDbuC2eEbaNKg7E245zLR6FgXqjwk_phOfQK8YHirU3KozUZP5rN78piyCInBfqUXbGfQi-IrSZyJo_hKgDCy1KmEynYIzQq7ArhGIgLTCbqHkFaAsKiWkjWpc_2yUqqBeEnj75oaQCL7NI5hTOHDQvn1jIVfSciE9sC9hVcCfPcy_Q6ep0jlThQAJlsA97BPBUrMYchvicOWuW1RnqdGswYqSyvGygitN25xIqMoKJflms4VK47NQbifeVXVNedZpiUXd_ec40fKitHFD8aCr5_CBnokuQvQjuOdSVG7j56M0aVc-CXkE2UzgTPJgp_yhPElNJ02OHxMJGmJDoPFsz8T7d67RU-CuEN7CdSs0SapoSFLT8uycCfMoYUmLErlxGkvci3WGY0INKimocMjZD3In0i7Re2vvtNpdwQaJd9fdGvNfkDutqVJQFfiK_EVOaxq6pPipVxNvqunyJJwWPF9j4V1lvEafc2xoxlUFSXbQ81D0yMlJOz92ssSX_9TN6emkqHZbOS8xt85E8IglxQORaY52t8hG5XwTJsFXGGgXCqSy3iyXxxsGkvrxvit6qHl0N9Wd1aed3enHK-pI9dSP-jEodAr6Xojml7XYSouCZVY7bLESdcn9kr36iAXzrscFy-gvEaVBLdhCvlEWXcA_lSqbRK3cas2yJd8YWtUO2X0O9rvcWTXfyrzJqaO-FF6GfRCG5X39aQlfmFCLZa_sD8t6vW6UxINBPOyP416aDvsttmXZoJ9ESTKIR6M0jodJmvTfWuxvoNeNRoNxf9BNe8M0SYfd4YjIkgyo75STlmXjt38Vsi5b
\ No newline at end of file
diff --git a/docs/guides/images/resource/advertiser-flow-overview-mermaid.md.bak b/docs/guides/images/resource/advertiser-flow-overview-v2-mermaid.md.bak
similarity index 100%
rename from docs/guides/images/resource/advertiser-flow-overview-mermaid.md.bak
rename to docs/guides/images/resource/advertiser-flow-overview-v2-mermaid.md.bak
diff --git a/docs/guides/images/resource/advertiser-flow-overview-v3-mermaid.mermaid b/docs/guides/images/resource/advertiser-flow-overview-v3-mermaid.mermaid
new file mode 100644
index 000000000..a1e32049c
--- /dev/null
+++ b/docs/guides/images/resource/advertiser-flow-overview-v3-mermaid.mermaid
@@ -0,0 +1,29 @@
+%%26/6/25: V3 API Update - Updated diagram to use V3 identity map API with refresh timestamps instead of salt bucket monitoring.
+
+ sequenceDiagram
+ participant ADP as Advertiser/Data Provider
+ participant UID as UID2 Operator
+ participant DSP
+ Note over ADP,DSP: 1. Generate raw UID2s from DII.
+ loop
+ ADP->>UID: 1-a. Send a request containing DII using an SDK, Snowflake, AWS Entity Resolution, or HTTP endpoint.
+ UID->>ADP: 1-b. Receive the raw UID2 (u), refresh timestamp (r), and optionally previous UID2 (p).
+ end
+ Note over ADP,DSP: 2. Store raw UID2s and refresh timestamps.
+ Note over ADP,DSP: 3. Manipulate or combine raw UID2s.
+ Note over ADP,DSP: 4. Send raw UID2s to DSPs.
+ ADP-->>DSP: Send stored raw UID2s to DSPs to create audiences and conversions, or use them for measurement.
+ Note over ADP,DSP: 5. Monitor for raw UID2 refresh.
+ loop
+ ADP->>ADP: 5-a. Check current time against stored refresh timestamps.
+ ADP->>UID: 5-b. If refresh time reached, resend DII to get updated raw UID2.
+ UID->>ADP: 5-c. Store the new raw UID2, refresh timestamp, and optionally previous UID2.
+ end
+ Note over ADP,DSP: 6. Monitor for opt-out status. Remove all opt-outs from local storage and do not use.
+ loop
+ ADP->>UID: 6-a. Monitor for optout status using the POST optout/status endpoint.
+ UID->>ADP: 6-b. Return optout status.
+ end
+
+%% URL:
+%% https://mermaid.live/edit#pako:eNqNVF1v2kAQ_Cure0ok44DBhvghUhSiFlVpUElVqeLlYh9win3n3gcpjfLfu2sbCAlU9Yt9552d3dm5e2GZzgVLGYAVv7xQmRhLvjS8nCvAp-LGyUxWXDm4Hk-BW7jO1wI3rTAXY-44TI1ey1yYj4DvkzEB8BXBfSUMd_pI1Hg2bTa_aidAY3JiCnA7hV4In4QipADDn-tUFhZGlzCeTMIGR0-hdQXNEsGdqyuMRHiHhzATKgcOhtqzDjKtHJdKqiWlAG_piyuYjb8EMFP6eVHwJxHA9Y8Z3Con3Qa-CasL76RWAWgDnx8epoBJKy2Va2tAOiRFaiJ9DBGSCbkW4Fb7wuHMnwdYx8IIuwInSyyHlxWcGdzmWKSuiIMXxQYqI9ZS-1a8s-q85UHak2JF2Csq_FYpyvqB0IYnU_RDuONKVr4gxbHXTJePUr1JudX8CHjQar2nd5qmu8XQYFCkOrYOtFTtkXh6Z0ZQCdznkkzZtIKzQ0aLItl6Et7WCpewwEUpuPVGlGI3lCM1xtigVhKJa8xuNK1ILZDctPNW46d6tDH56WYlsifIvDHIVKsKfImOQm9tGzql-KE7YzLKZHEQjguerUROPrGkEXkU5VgKB77KUZK9Xvukb9wXd7KtDch7Sjzv4o9479---w_PJYd6YqaO9iQEd97SMSgxHjD19ld7egud8aLWiy9FXUSuQWlHIz09hFq2hIbwjnTP2R5o6n16P3tof160P9-d2kPpkubgOm_UYc69DixgSyNzljrjRcBKYUpOS_ZCIXNGZhRzluInVoYaz9lcvSIKb7qfWpdboNF-uWLpghcWV81g23t3t8u907ONyraYJuo2p753QaJe3jV3eH2V11wsfWG_WdrrdcM4GgyiYf8y6iXJsB-wDUsH_TiM40E0GiVRNIyTuP8asD91ed1wNLjsD7pJb5jEybA7HGGx2LgwN9orhyn7r38BOSL5zQ
\ No newline at end of file
diff --git a/docs/guides/integration-advertiser-dataprovider-endpoints.md b/docs/guides/integration-advertiser-dataprovider-endpoints.md
index 1f523e229..295ef05b3 100644
--- a/docs/guides/integration-advertiser-dataprovider-endpoints.md
+++ b/docs/guides/integration-advertiser-dataprovider-endpoints.md
@@ -38,13 +38,13 @@ At a high level, the steps for advertisers and data providers integrating with U
1. [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii)
-2. [Store Raw UID2s and Salt Bucket IDs](#2-store-raw-uid2s-and-salt-bucket-ids)
+2. [Store Raw UID2s and Refresh Timestamps](#2-store-raw-uid2s-and-refresh-timestamps)
3. [Manipulate or Combine Raw UID2s](#3-manipulate-or-combine-raw-uid2s)
4. [Send Stored Raw UID2s to DSPs to Create Audiences or Conversions](#4-send-stored-raw-uid2s-to-dsps-to-create-audiences-or-conversions)
-5. [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s)
+5. [Monitor for Raw UID2 Refresh](#5-monitor-for-raw-uid2-refresh)
6. [Monitor for Opt-Out Status](#6-monitor-for-opt-out-status)
@@ -54,31 +54,31 @@ The following diagram outlines the steps that data collectors must complete to m
DII refers to a user's normalized email address or phone number, or the normalized and SHA-256-hashed email address or phone number.
-
+
-
+
### 1: Generate Raw UID2s from DII
| Step | Endpoint | Description |
| --- | --- | --- |
| 1-a | [POST /identity/map](../endpoints/post-identity-map.md) request | Send a request containing DII to the identity mapping endpoint. |
-| 1-b | [POST /identity/map](../endpoints/post-identity-map.md) response | The `advertising_id` (raw UID2) returned in the response can be used to target audiences on relevant DSPs. The response returns a user's raw UID2 and the corresponding `bucket_id` for the salt bucket. The salt assigned to the bucket rotates annually, which impacts the generated raw UID2. For details on how to check for salt bucket rotation, see [5: Monitor for salt bucket rotations related to your stored raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s). |
-
+| 1-b | [POST /identity/map](../endpoints/post-identity-map.md) response | The raw UID2 (`u` field) returned in the response can be used to target audiences on relevant DSPs. The response returns a user's raw UID2 (`u`), refresh timestamp (`r`), and optionally the previous raw UID2 (`p`) if the current UID2 was rotated within the last 90 days. Use the refresh timestamp to determine when to refresh the UID2. For details, see [5: Monitor for Raw UID2 Refresh](#5-monitor-for-raw-uid2-refresh). |
-### 2: Store Raw UID2s and Salt Bucket IDs
+### 2: Store Raw UID2s and Refresh Timestamps
The response from Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii), contains mapping information. We recommend that you store the following information returned in Step 1:
-- Cache the mapping between DII (`identifier`), raw UID2 (`advertising_id`), and salt bucket (`bucket_id`).
-- Store the timestamp for when you received the response data. Later, you can compare this timestamp with the `last_updated` timestamp returned in Step 5, [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s).
+- Cache the mapping between DII and raw UID2 (`u` field).
+- Store the refresh timestamp (`r` field) to know when the raw UID2 could refresh.
+- Optionally store the previous raw UID2 (`p` field) if provided for users whose UID2 was refreshed within the last 90 days.
### 3: Manipulate or Combine Raw UID2s
Use the UID2s you received in Step 1. For example, you might do one or more of the following:
-- Do some manipulation: for example, combine UID2s you generated from DII and UID2s received from another participant such as an advertiser or data provider.
-- Add new UID2s into an existing audience.
+- Do some manipulation: for example, combine raw UID2s you generated from DII and raw UID2s received from another participant such as an advertiser or data provider.
+- Add new raw UID2s into an existing audience.
### 4: Send Stored Raw UID2s to DSPs to Create Audiences or Conversions
@@ -87,42 +87,37 @@ Use the raw UID2s for some purpose such as:
- Sending stored raw UID2s to DSPs to create audiences and conversions.
- Using the raw UID2s for measurement.
-For example, you could send the `advertising_id` (raw UID2) returned in Step 1-b to a DSP while building your audiences. Each DSP has a unique integration process for building audiences; follow the integration guidance provided by the DSP for sending raw UID2s to build an audience.
+For example, you could send the (raw UID2) (`u` field) returned in Step 1-b to a DSP while building your audiences. Each DSP has a unique integration process for building audiences; follow the integration guidance provided by the DSP for sending raw UID2s to build an audience.
You could also send conversion information via API or pixels for measurement (attribution) or for retargeting.
-### 5: Monitor for Salt Bucket Rotations for Your Stored Raw UID2s
+### 5: Monitor for Raw UID2 Refresh
-A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes at least once per year, as a result of the salt bucket rotation.
+A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes roughly once per year as part of the UID2 refresh process.
-Even though each salt bucket is updated approximately once per year, individual bucket updates are spread over the year. Approximately 1/365th of all salt buckets are rotated daily. Based on this, we recommend checking salt bucket rotation regularly, on a cadence that aligns with your audience refreshes. For example, if you refresh weekly, check for salt bucket updates weekly.
+The v3 Identity Map API provides a refresh timestamp (`r` field) in the response that indicates when each raw UID2 might refresh. Use this timestamp to determine when to regenerate raw UID2s for your stored data, it is guaranteed that it won't refresh before that time.
-If the salt bucket has been rotated, regenerate the raw UID2. For details, see [Determine whether the salt bucket has been rotated](#determine-whether-the-salt-bucket-has-been-rotated).
-
-The following table shows the steps for checking for salt bucket rotation.
+We recommend checking for refresh opportunities daily. The following table shows the steps for monitoring raw UID2 refresh.
-| Step | Endpoint | Description |
-| --- | --- | --- |
-| 5-a | [POST /identity/buckets](../endpoints/post-identity-buckets.md) | Send a request to the `POST /identity/buckets` endpoint for all salt buckets that have changed since a specific timestamp. |
-| 5-b | [POST /identity/buckets](../endpoints/post-identity-buckets.md) | UID2 service: The `POST /identity/buckets` endpoint returns a list of `bucket_id` and `last_updated` timestamps. |
-| 5-c | [POST /identity/map](../endpoints/post-identity-map.md) | Compare the returned `bucket_id` to the salt buckets of raw UID2s that you've cached. If you find that the salt bucket was updated for one or more raw UID2s, re-send the DII to the `POST /identity/map` endpoint for a new raw UID2. |
-| 5-d | [POST /identity/map](../endpoints/post-identity-map.md) | Store the new values returned for `advertising_id` and `bucket_id`. |
+| Step | Action | Description |
+| :--- | :--- | :--- |
+| 5-a | Local timestamp check | Compare the current time with the refresh timestamp (`r` field) you stored from the [POST /identity/map](../endpoints/post-identity-map.md) response previously. |
+| 5-b | [POST /identity/map](../endpoints/post-identity-map.md) | If the current time is greater than or equal to the refresh timestamp, regenerate the raw UID2 by calling the identity map endpoint again with the same DII. |
+| 5-c | Local storage update | Store the new raw UID2 (`u` field), refresh timestamp (`r` field) and optionally previous UID2 (`p` field) returned from the response. |
-#### Determine whether the salt bucket has been rotated
+#### Determine whether to refresh a raw UID2
-To determine whether the salt bucket ID for a specific raw UID2 has changed, follow these steps.
+To determine whether to refresh a raw UID2, follow these steps:
-1. Compare these two values:
+1. Compare the current time with the refresh timestamp (`r` field) you stored from the [POST /identity/map](../endpoints/post-identity-map.md) response.
- - The `last_updated` timestamp of each `bucket_id` returned as part of monitoring the salt bucket rotations.
-
- - The timestamp of the raw UID2 generation of the same `bucket_id`, which was returned in Step 1 and stored in Step 2.
+2. If the current time is greater than or equal to the refresh timestamp, regenerate the raw UID2 by calling [POST /identity/map](../endpoints/post-identity-map.md) again with the same DII.
-1. If the `last_updated` timestamp is more recent than the timestamp you recorded earlier, the salt bucket has been rotated. As a result, you'll need to regenerate any raw UID2s associated with this `bucket_id`, following Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii).
+This approach ensures your raw UID2s remain current and valid for audience targeting and measurement.
### 6: Monitor for Opt-Out Status
-It's important to honor user opt-out status. Periodically, monitor for opt-out status, to be sure that you don't continue using UID2s for users that have recently opted out.
+It's important to honor user opt-out status. Periodically, monitor for opt-out status, to be sure that you don't continue using raw UID2s for users that have recently opted out.
There are two ways that you can check with the UID2 Operator Service to make sure you have the latest opt-out information:
@@ -131,3 +126,68 @@ There are two ways that you can check with the UID2 salt bucket rotation.
+
+Even though each salt bucket is updated approximately once per year, individual bucket updates are spread over the year. Approximately 1/365th of all salt buckets are rotated daily. Based on this, we recommend checking salt bucket rotation regularly, on a cadence that aligns with your audience refreshes. For example, if you refresh weekly, check for salt bucket updates weekly.
+
+If the salt bucket has been rotated, regenerate the raw UID2. For details, see [Determine whether the salt bucket has been rotated](#determine-whether-the-salt-bucket-has-been-rotated).
+
+The following table shows the steps for checking for salt bucket rotation.
+
+| Step | Endpoint | Description |
+| --- | --- | --- |
+| 5-a | [POST /identity/buckets](../endpoints/post-identity-buckets.md) | Send a request to the `POST /identity/buckets` endpoint for all salt buckets that have changed since a specific timestamp. |
+| 5-b | [POST /identity/buckets](../endpoints/post-identity-buckets.md) | UID2 service: The `POST /identity/buckets` endpoint returns a list of `bucket_id` and `last_updated` timestamps. |
+| 5-c | [POST /identity/map](../endpoints/post-identity-map-v2.md) | Compare the returned `bucket_id` to the salt buckets of raw UID2s that you've cached. If you find that the salt bucket was updated for one or more raw UID2s, re-send the DII to the `POST /identity/map` endpoint for a new raw UID2. |
+| 5-d | [POST /identity/map](../endpoints/post-identity-map-v2.md) | Store the new values returned for `advertising_id` and `bucket_id`. |
+
+##### Determine whether the salt bucket has been rotated
+
+To determine whether the salt bucket ID for a specific raw UID2 has changed, follow these steps.
+
+1. Compare these two values:
+
+ - The `last_updated` timestamp of each `bucket_id` returned as part of monitoring the salt bucket rotations.
+
+ - The timestamp of the raw UID2 generation of the same `bucket_id`, which was returned in Step 1 and stored in Step 2.
+
+1. If the `last_updated` timestamp is more recent than the timestamp you recorded earlier, the salt bucket has been rotated. As a result, you'll need to regenerate any raw UID2s associated with this `bucket_id`, following Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii).
diff --git a/docs/guides/integration-advertiser-dataprovider-overview.md b/docs/guides/integration-advertiser-dataprovider-overview.md
index 651abf6f2..ad77d0850 100644
--- a/docs/guides/integration-advertiser-dataprovider-overview.md
+++ b/docs/guides/integration-advertiser-dataprovider-overview.md
@@ -23,9 +23,9 @@ There are other ways that you can use UID2, outside these use cases. These are j
| Send/Receive? | Action | Advantage/Result |
| --- | --- | --- |
-| Send in audiences | Send UID2s via API or pixels | Create audiences. |
-| Send in conversions | Send UID2s as conversion information | Use conversion information for measurement (attribution) or for retargeting via API or pixels. |
-| Receive graph data | Receive UID2s from graph/data providers via API or pixels | Build graph data. |
+| Send in audiences | Send raw UID2s via API or pixels | Create audiences. |
+| Send in conversions | Send raw UID2s as conversion information | Use conversion information for measurement (attribution) or for retargeting via API or pixels. |
+| Receive graph data | Receive raw UID2s from graph/data providers via API or pixels | Build graph data. |
## High-Level Steps
@@ -33,16 +33,20 @@ At a high level, the steps for advertisers and data providers integrating with U
1. [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii)
-2. [Store Raw UID2s and Salt Bucket IDs](#2-store-raw-uid2s-and-salt-bucket-ids)
+2. [Store Raw UID2s and Refresh Timestamps](#2-store-raw-uid2s-and-refresh-timestamps)
3. [Manipulate or Combine Raw UID2s](#3-manipulate-or-combine-raw-uid2s)
4. [Send Stored Raw UID2s to DSPs to Create Audiences or Conversions](#4-send-stored-raw-uid2s-to-dsps-to-create-audiences-or-conversions)
-5. [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s)
+5. [Monitor for Raw UID2 Refresh](#5-monitor-for-raw-uid2-refresh)
6. [Monitor for Opt-Out Status](#6-monitor-for-opt-out-status)
+:::note
+If your implementation uses a version of the [POST /identity/map](../endpoints/post-identity-map.md) endpoint earlier than version 3, see [Using POST /identity/map Version 2](#using-post-identitymap-version-2). If you're using this version, we recommend you upgrade as soon as possible to take advantage of the enhancements.
+:::
+
## Summary of Implementation Options
The following table shows the implementation options that are available for advertisers and data providers, for each of the high-level steps. Some steps are managed solely as part of your own custom implementation; some steps can be managed by one or more of the UID2 implementation options available. For details, click the link on each step.
@@ -50,10 +54,10 @@ The following table shows the implementation options that are available for adve
| High-Level Step | Implementation Options |
| --- | --- |
| [1: Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii) | Use any of the following options to map DII to raw UID2s:
One of these UID2 SDKs:
Python SDK: [Map DII to Raw UID2s](../sdks/sdk-ref-python.md#map-dii-to-raw-uid2s)
Java SDK: [Usage for Advertisers/Data Providers](../sdks/sdk-ref-java.md#usage-for-advertisersdata-providers)
|
-| [2: Store Raw UID2s and Salt Bucket IDs](#2-store-raw-uid2s-and-salt-bucket-ids) | Custom (your choice). |
+| [2: Store Raw UID2s and Refresh Timestamps](#2-store-raw-uid2s-and-refresh-timestamps) | Custom (your choice). |
| [3: Manipulate or Combine Raw UID2s](#3-manipulate-or-combine-raw-uid2s) | Custom (your choice). |
| [4: Send Stored Raw UID2s to DSPs to Create Audiences or Conversions](#4-send-stored-raw-uid2s-to-dsps-to-create-audiences-or-conversions) | Custom (your choice). |
-| [5: Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s) | Any of the following options:
Python SDK: see SDK for Python Reference Guide
Snowflake: see Snowflake Integration Guide, section titled Monitor for Salt Bucket Rotation and Regenerate Raw UID2s
Raw HTTP endpoint: POST /identity/buckets
|
+| [5: Monitor for Raw UID2 Refresh](#5-monitor-for-raw-uid2-refresh) | Use the refresh timestamp (`r` field) returned from the [POST /identity/map](../endpoints/post-identity-map.md) endpoint to determine when to refresh Raw UID2s. |
| [6: Monitor for Opt-Out Status](#6-monitor-for-opt-out-status) | API call to the [POST /optout/status](../endpoints/post-optout-status.md) endpoint. |
## Integration Diagram
@@ -64,9 +68,9 @@ DII refers to a user's normalized email address or phone number, or the normaliz
To keep your UID2-based audience information accurate and up to date, follow these integration steps every day.
-
+
-
+
For details about the different parts of the diagram, refer to the following sections.
@@ -87,19 +91,20 @@ To generate raw UID2s, use one of the following options:
- HTTP endpoints: [POST /identity/map](../endpoints/post-identity-map.md). For details, see [Generate Raw UID2s from DII](integration-advertiser-dataprovider-endpoints.md#1-generate-raw-uid2s-from-dii).
-### 2: Store Raw UID2s and Salt Bucket IDs
+### 2: Store Raw UID2s and Refresh Timestamps
The response from Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii), contains mapping information. We recommend that you store the following information returned in Step 1:
-- Cache the mapping between DII (`identifier`), raw UID2 (`advertising_id`), and salt bucket (`bucket_id`).
-- Store the timestamp for when you received the response data. Later, you can compare this timestamp with the `last_updated` timestamp returned in Step 5, [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s).
+- Cache the mapping between DII and raw UID2 (`u` field).
+- Store the refresh timestamp (`r` field) to know when the raw UID2 could refresh.
+- Optionally store the previous raw UID2 (`p` field) if provided for users whose UID2 was refreshed within the last 90 days.
### 3: Manipulate or Combine Raw UID2s
-Use the UID2s you received in Step 1. For example, you might do one or more of the following:
+Use the raw UID2s you received in Step 1. For example, you might do one or more of the following:
-- Do some manipulation: for example, combine UID2s you generated from DII and UID2s received from another participant such as an advertiser or data provider.
-- Add new UID2s into an existing audience.
+- Do some manipulation: for example, combine raw UID2s you generated from DII and raw UID2s received from another participant such as an advertiser or data provider.
+- Add new raw UID2s into an existing audience.
### 4: Send Stored Raw UID2s to DSPs to Create Audiences or Conversions
@@ -108,17 +113,79 @@ Use the raw UID2s for some purpose such as:
- Sending stored raw UID2s to DSPs to create audiences and conversions.
- Using the raw UID2s for measurement.
-For example, you could send the `advertising_id` (raw UID2) returned in Step 1-b to a DSP while building your audiences. Each DSP has a unique integration process for building audiences; follow the integration guidance provided by the DSP for sending raw UID2s to build an audience.
+For example, you could send the (raw UID2 (`u` field) returned in Step 1 to a DSP while building your audiences. Each DSP has a unique integration process for building audiences; follow the integration guidance provided by the DSP for sending raw UID2s to build an audience.
You could also send conversion information via API or pixels for measurement (attribution) or for retargeting.
-### 5: Monitor for Salt Bucket Rotations for Your Stored Raw UID2s
+### 5: Monitor for Raw UID2 Refresh
+
+A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes roughly once per year as part of the UID2 refresh process.
+
+The v3 Identity Map API provides a refresh timestamp (`r` field) in the response that indicates when each raw UID2 might refresh. Use this timestamp to determine when to regenerate raw UID2s for your stored data. It is guaranteed that it won't refresh before that time.
+
+We recommend checking for refresh opportunities daily. To determine whether to refresh a raw UID2:
+
+1. Compare the current time with the refresh timestamp (`r` field) you stored from the [POST /identity/map](../endpoints/post-identity-map.md) response.
+
+2. If the current time is greater than or equal to the refresh timestamp, regenerate the raw UID2 by calling [POST /identity/map](../endpoints/post-identity-map.md) again with the same DII.
+
+This approach ensures your raw UID2s remain current and valid for audience targeting and measurement.
+
+### 6: Monitor for Opt-Out Status
+
+It's important to honor user opt-out status. Periodically, monitor for opt-out status, to be sure that you don't continue using raw UID2s for users that have recently opted out.
+
+There are two ways that you can check with the UID2 Operator Service to make sure you have the latest opt-out information:
+
+- Call the [POST /identity/map](../endpoints/post-identity-map.md) endpoint to check for opt-outs. If the DII has been opted out, no raw UID2 is generated.
+
+- Check the opt-out status of raw UID2s using the [POST /optout/status](../endpoints/post-optout-status.md) endpoint.
+
+For details about the UID2 opt-out workflow and how users can opt out, see [User Opt-Out](../getting-started/gs-opt-out.md).
+
+## Using POST /identity/map Version 2
+
+:::note
+The following information is relevant only to integration approaches that use an earlier version of the `POST /identity/map` endpoint, version 2, and is provided for reference only. New implementations should use the latest version: see [High-Level Steps](#high-level-steps).
+:::
+
+The key differences when using v2 of the Identity Map API are:
+
+- **Step 2**: Store salt bucket IDs instead of refresh timestamps
+- **Step 5**: Monitor for salt bucket rotations instead of using refresh timestamps
+
+All other steps (1, 3, 4, and 6) are the same as described in the v3 implementation: see [High-Level Steps](#high-level-steps).
-A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes at least once per year, as a result of the salt bucket rotation.
+### Integration Diagram (v2)
+
+The following diagram outlines the v2 integration flow. Note that the main differences are in Step 2 (storing salt bucket IDs) and Step 5 (monitoring salt bucket rotations).
+
+
+
+
+
+### Store Raw UID2s and Salt Bucket IDs (v2)
+
+:::note
+This step replaces Step 2 in the v3 implementation.
+:::
+
+The response from Step 1 contains mapping information. We recommend that you store the following information returned in Step 1:
+
+- Cache the mapping between DII (`identifier`), raw UID2 (`advertising_id`), and salt bucket (`bucket_id`).
+- Store the timestamp for when you received the response data. Later, you can compare this timestamp with the `last_updated` timestamp returned in Step 5.
+
+### Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)
+
+:::note
+This step replaces Step 5 in the v3 implementation.
+:::
+
+A raw UID2 is an identifier for a user at a specific moment in time. The raw UID2 for a specific user changes roughly once per year, as a result of the salt bucket rotation.
Even though each salt bucket is updated approximately once per year, individual bucket updates are spread over the year. Approximately 1/365th of all salt buckets are rotated daily. Based on this, we recommend checking salt bucket rotation regularly, on a cadence that aligns with your audience refreshes. For example, if you refresh weekly, check for salt bucket updates weekly.
-If the salt bucket has been rotated, regenerate the raw UID2. For details, see [Determine whether the salt bucket has been rotated](#determine-whether-the-salt-bucket-has-been-rotated).
+If the salt bucket has been rotated, regenerate the raw UID2. For details, see [Determine whether the salt bucket has been rotated](#determine-whether-the-salt-bucket-has-been-rotated-v2).
For instructions for monitoring for salt bucket rotations, refer to one of the following:
@@ -126,35 +193,23 @@ For instructions for monitoring for salt bucket rotations, refer to one of the f
- Snowflake: [Monitor for Salt Bucket Rotation and Regenerate Raw UID2s](integration-snowflake.md#monitor-for-salt-bucket-rotation-and-regenerate-raw-uid2s).
-- HTTP endpoints: [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s](integration-advertiser-dataprovider-endpoints.md#5-monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s).
+- HTTP endpoints: [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)](integration-advertiser-dataprovider-endpoints.md#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
:::note
For AWS Entity Resolution, there is no way to do salt bucket monitoring. As an alternative, you could regenerate raw UID2s periodically using the AWS Entity Resolution service.
:::
-#### Determine whether the salt bucket has been rotated
+##### Determine whether the salt bucket has been rotated (v2)
To determine whether the salt bucket ID for a specific raw UID2 has changed, follow these steps.
1. Compare these two values:
- - The `last_updated` timestamp of each `bucket_id` returned as part of monitoring the salt bucket rotations (whatever option you choose).
-
- - The timestamp of the raw UID2 generation of the same `bucket_id`, which was returned in Step 1 and stored in Step 2.
-
-1. If the `last_updated` timestamp is more recent than the timestamp you recorded earlier, the salt bucket has been rotated. As a result, you'll need to regenerate any raw UID2s associated with this `bucket_id`, following Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii).
-
-### 6: Monitor for Opt-Out Status
-
-It's important to honor user opt-out status. Periodically, monitor for opt-out status, to be sure that you don't continue using UID2s for users that have recently opted out.
+ - The `last_updated` timestamp of each `bucket_id` returned as part of monitoring the salt bucket rotations (whatever option you choose).
-There are two ways that you can check with the UID2 Operator Service to make sure you have the latest opt-out information:
-
-- Call the [POST /identity/map](../endpoints/post-identity-map.md) endpoint to check for opt-outs. If the DII has been opted out, no raw UID2 is generated.
+ - The timestamp of the raw UID2 generation of the same `bucket_id`, which was returned in Step 1 and stored in Step 2.
-- Check the opt-out status of raw UID2s using the [POST /optout/status](../endpoints/post-optout-status.md) endpoint.
-
-For details about the UID2 opt-out workflow and how users can opt out, see [User Opt-Out](../getting-started/gs-opt-out.md).
+1. If the `last_updated` timestamp is more recent than the timestamp you recorded earlier, the salt bucket has been rotated. As a result, you'll need to regenerate any raw UID2s associated with this `bucket_id`, following Step 1, [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii).
## FAQs
diff --git a/docs/overviews/images/UID2AdvertiserAndThirdPartyDataProviderWorkflow.svg b/docs/overviews/images/UID2AdvertiserAndThirdPartyDataProviderWorkflow.svg
index 477af3b9c..408dd424e 100644
--- a/docs/overviews/images/UID2AdvertiserAndThirdPartyDataProviderWorkflow.svg
+++ b/docs/overviews/images/UID2AdvertiserAndThirdPartyDataProviderWorkflow.svg
@@ -1,30 +1,30 @@
diff --git a/docs/overviews/images/source/source.txt b/docs/overviews/images/source/source.txt
index 8aab7fab4..d4cd1c6e4 100644
--- a/docs/overviews/images/source/source.txt
+++ b/docs/overviews/images/source/source.txt
@@ -4,4 +4,6 @@ Source is the same as for the workflow diagrams in docs/overviews/images, for UI
https://www.figma.com/file/43lE7yuZ2NWflmBdcJNBkw/UID2-Workflows?type=design&node-id=28%3A2&mode=design&t=ehOn5ACoXYTyK6aU-1
-updated 6 May 2024
\ No newline at end of file
+updated 6 May 2024
+
+Last update 9 July 25 for POST /identity/map updates
\ No newline at end of file
diff --git a/docs/overviews/overview-advertisers.md b/docs/overviews/overview-advertisers.md
index 11042bba0..bd4b5151d 100644
--- a/docs/overviews/overview-advertisers.md
+++ b/docs/overviews/overview-advertisers.md
@@ -39,15 +39,15 @@ Here are just some of the intended benefits of using UID2 as part of your advert
The following steps provide a high-level outline of the workflow intended for organizations that collect user data and push it to DSPs—for example, advertisers, identity graph providers, and third-party data providers.
The following process occurs in the background:
-* The advertiser or data provider monitors the UID2 Operator for rotated salt buckets and updates UID2s as needed.
+* The advertiser or data provider monitors refresh timestamps and updates UID2s when the current time exceeds the refresh timestamp for each stored UID2.
The following steps are an example of how an advertiser can integrate with UID2:
1. The advertiser sends a user’s directly identifying information (DII) to the UID2 Operator.
-2. The UID2 Operator generates and returns a raw UID2 and salt bucket ID.
-3. The advertiser stores the UID2 and salt bucket ID and sends the UID2-based first-party and third-party audience segments to the DSP.
+2. The UID2 Operator generates and returns a raw UID2 and refresh timestamp.
+3. The advertiser stores the UID2 and refresh timestamp and sends the UID2-based first-party and third-party audience segments to the DSP.
- Server-side: The advertiser stores the UID2 in a mapping table, DMP, data lake, or other server-side application.
+ Server-side: The advertiser stores the UID2 and refresh timestamp in a mapping table, DMP, data lake, or other server-side application.

diff --git a/docs/overviews/overview-data-providers.md b/docs/overviews/overview-data-providers.md
index 5c17c580c..9da97cbfa 100644
--- a/docs/overviews/overview-data-providers.md
+++ b/docs/overviews/overview-data-providers.md
@@ -44,15 +44,15 @@ Here are just some of the intended benefits available to you as a data provider
The following steps provide a high-level outline of the workflow intended for organizations that collect user data and push it to DSPs—for example, advertisers, identity graph providers, and third-party data providers.
The following process occurs in the background:
-* The advertiser or data provider monitors the UID2 Operator for rotated salt buckets, and updates UID2s as needed.
+* The advertiser or data provider monitors refresh timestamps and updates UID2s when the current time exceeds the refresh timestamp for each stored UID2.
The following steps are an example of how a data provider can integrate with UID2:
1. The data provider sends a user’s directly identifying information (DII) to the UID2 Operator.
-2. The UID2 Operator generates and returns a raw UID2 and salt bucket ID.
-3. The data provider stores the UID2 and salt bucket ID and sends the UID2-based first-party and third-party audience segments to the DSP.
+2. The UID2 Operator generates and returns a raw UID2 and refresh timestamp.
+3. The data provider stores the UID2 and refresh timestamp and sends the UID2-based first-party and third-party audience segments to the DSP.
- Server-side: The data provider stores the UID2 in a mapping table, DMP, data lake, or other server-side application.
+ Server-side: The data provider stores the UID2 and refresh timestamp in a mapping table, DMP, data lake, or other server-side application.

diff --git a/docs/ref-info/glossary-uid.md b/docs/ref-info/glossary-uid.md
index 51a13e752..2c2c663f2 100644
--- a/docs/ref-info/glossary-uid.md
+++ b/docs/ref-info/glossary-uid.md
@@ -91,6 +91,7 @@ import MdxJumpAnchor from '@site/src/components/MdxJumpAnchor';
**R**
Raw UID2 |
+Refresh timestamp |
Refresh token
**S**
@@ -372,7 +373,7 @@ import MdxJumpAnchor from '@site/src/components/MdxJumpAnchor';
An entity that fulfils a key role in UID2. Participants include the following: Core Administrator, Operator, DSP, data provider, advertiser, publisher, consumer.
+
An entity that fulfils a key role in UID2. Participants include the following: Core Administrator, Operator, DSP, data provider, advertiser, publisher, and consumer.
@@ -400,6 +401,10 @@ import MdxJumpAnchor from '@site/src/components/MdxJumpAnchor';
An unencrypted alphanumeric identifier created through the UID2 APIs or SDKs with the user's directly identifying information (email address or phone number) as input. The raw UID2 is encrypted to create a UID2 token. The raw UID2 is a unique value; no two raw UID2s are the same. Raw UID2s, and their associated UID2 tokens, are case sensitive.
In the context of mapping DII to raw UID2s, a refresh timestamp is a Unix timestamp (in seconds) returned in the r field of the POST /identity/map endpoint response. The raw UID2 is guaranteed to be valid until this timestamp. It is refreshed at some point after this time.
+
Use the refresh timestamp to determine when to regenerate raw UID2s for your stored data. We recommend checking for refresh opportunities daily by comparing the current time with the stored refresh timestamps.
A refresh token is an opaque string that is issued along with the UID2 token. It is used to refresh the UID2 token, which has a limited life.
When the UID2 server receives the refresh token with a request for a new UID2 token, it checks for user opt-out. If the user has opted out of UID2, no new UID2 token is generated.
@@ -418,10 +423,12 @@ import MdxJumpAnchor from '@site/src/components/MdxJumpAnchor';
A salt bucket is used to manage secret salt values, used to generate raw UID2s or UID2 tokens, over time. Each bucket contains a single current salt value, which remains active for approximately one year before being rotated to a new value. Buckets can be updated independently of one another.
There are just over one million salt buckets, and each email address or phone number is assigned to a specific bucket in a deterministic manner. However, this assignment is not permanent; it might change when the bucket's current salt is rotated to a new value.
+
In versions of the [POST /identity/map](../endpoints/post-identity-map.md) endpoint earlier than version 3, such as [POST /identity/map (v2)](../endpoints/post-identity-map-v2.md), the endpoint returns salt bucket IDs. In v3 and later, salt bucket information is not needed.
A salt bucket ID is a unique string of characters that identifies a specific salt bucket. The salt bucket ID can be used to check which salt buckets have recently had their salt values updated, indicating which emails or phone numbers need their raw UID2 values regenerated.
-
For an example of a salt bucket ID, see the response to the `POST /identity/buckets` endpoint: Decrypted JSON Response Format.
+
In versions of the [POST /identity/map](../endpoints/post-identity-map.md) endpoint earlier than version 3, such as [POST /identity/map (v2)](../endpoints/post-identity-map-v2.md), the endpoint returns salt bucket IDs. In v3 and later, salt bucket information is not needed.
+
For an example of a salt bucket ID, see the response to the `POST /v2/identity/buckets` endpoint: Decrypted JSON Response Format. If you're using `POST /v3/identity/map`, you don't need to use `POST /v2/identity/buckets` at all.
When a salt value is added to the input string before applying the hash function, the result is a salted hash. When the input value is salted before hashing, an attacker who has the hash cannot determine the input value by trying many possible inputs to arrive at the same output.
diff --git a/docs/ref-info/images/UID2Workflows.svg b/docs/ref-info/images/UID2Workflows.svg
index 04c601011..da56f41e7 100644
--- a/docs/ref-info/images/UID2Workflows.svg
+++ b/docs/ref-info/images/UID2Workflows.svg
@@ -6,8 +6,8 @@
-
-
+
+
@@ -25,9 +25,9 @@
-
-
-
+
+
+
@@ -49,16 +49,16 @@
-
-
+
+
-
-
+
+
-
-
+
+
@@ -96,9 +96,9 @@
-
+
-
+
@@ -165,7 +165,7 @@
-
-
+
+
diff --git a/docs/ref-info/updates-doc.md b/docs/ref-info/updates-doc.md
index 62772d0e3..d04df3f7b 100644
--- a/docs/ref-info/updates-doc.md
+++ b/docs/ref-info/updates-doc.md
@@ -20,6 +20,22 @@ Check out the latest updates to our UID2 documentation resources.
Use the Tags toolbar to view a subset of documentation updates.
:::
+## Q3 2025
+
+The following documents were released in this quarter.
+
+
+
+### Identity Map v3
+
+July 11, 2025
+
+We've released a new version of the Identity Map API (v3) that provides significant improvements for advertisers and data providers. This update includes documentation for the [POST /identity/map](../endpoints/post-identity-map.md) endpoint, the [SDK for Java Reference Guide](../sdks/sdk-ref-java.md#usage-for-advertisersdata-providers), and the [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
+
+
+
+
+
## Q1 2025
The following documents were released in this quarter.
@@ -423,7 +439,7 @@ For details, see [UID2 Hashing Tool](../getting-started/gs-normalization-encodin
February 28, 2024
-The Java SDK now supports Advertisers and Data Providers wanting to use the [POST /identity/map](../endpoints/post-identity-map.md) endpoint.
+The Java SDK now supports Advertisers and Data Providers wanting to use the [POST /identity/map (v2)](../endpoints/post-identity-map-v2.md) endpoint.
For details, see the updated documentation in the *SDK for Java Reference Guide*: [Usage for Advertisers and Data Providers](../sdks/sdk-ref-java.md#usage-for-advertisersdata-providers).
diff --git a/docs/sdks/sdk-ref-java.md b/docs/sdks/sdk-ref-java.md
index 5b4abc707..392d9e5c9 100644
--- a/docs/sdks/sdk-ref-java.md
+++ b/docs/sdks/sdk-ref-java.md
@@ -145,7 +145,7 @@ If you're using the SDK's HTTP implementation, follow these steps.
2. Call a function that takes the user's email address or phone number as input and generates a `TokenGenerateResponse` object. The following example uses an email address:
```java
- TokenGenerateResponse tokenGenerateResponse = publisherUid2Client.generateTokenResponse(TokenGenerateInput.fromEmail(emailAddress).doNotGenerateTokensForOptedOut());
+ TokenGenerateResponse tokenGenerateResponse = publisherUid2Client.generateTokenResponse(TokenGenerateInput.fromEmail("user@example.com").doNotGenerateTokensForOptedOut());
```
:::important
@@ -193,7 +193,9 @@ If you're using server-side integration (see [Publisher Integration Guide, Serve
2. Determine if the identity can be refreshed (that is, the refresh token hasn't expired):
```java
- if (identity == null || !identity.isRefreshable()) { we must no longer use this identity (for example, remove this identity from the user's session) }
+ if (identity == null || !identity.isRefreshable()) {
+ // we must no longer use this identity (for example, remove this identity from the user's session)
+ }
```
3. Determine if a refresh is needed:
@@ -220,13 +222,13 @@ If you're using server-side integration (see [Publisher Integration Guide, Serve
2. Call a function that takes the user's email address or phone number as input and creates a secure request data envelope. See [Encrypting requests](../getting-started/gs-encryption-decryption.md#encrypting-requests). The following example uses an email address:
```java
- EnvelopeV2 envelope = publisherUid2Helper.createEnvelopeForTokenGenerateRequest(TokenGenerateInput.fromEmail(emailAddress).doNotGenerateTokensForOptedOut());
+ EnvelopeV2 envelope = publisherUid2Helper.createEnvelopeForTokenGenerateRequest(TokenGenerateInput.fromEmail("user@example.com").doNotGenerateTokensForOptedOut());
```
3. Using an HTTP client library of your choice, post this envelope to the [POST token/generate](../endpoints/post-token-generate.md) endpoint, including headers and body:
1. Headers: Depending on your HTTP library, this might look something like the following:
`.putHeader("Authorization", "Bearer " + UID2_API_KEY)`
- `.putHeader("X-UID2-Client-Version", PublisherUid2Helper.getVersionHeader())`
+ `.putHeader("X-UID2-Client-Version", PublisherUid2Helper.getVersionHttpHeader())`
2. Body: `envelope.getEnvelope()`
:::important
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map-v2.md b/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map-v2.md
new file mode 100644
index 000000000..95f88bf30
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map-v2.md
@@ -0,0 +1,199 @@
+---
+title: POST /identity/map (v2)
+description: DII を raw UID2 とソルトバケット ID にマッピング。
+hide_table_of_contents: false
+sidebar_position: 07
+---
+
+import Link from '@docusaurus/Link';
+
+# POST /identity/map (v2)
+
+複数のメールアドレス、電話番号、またはそれぞれのハッシュを、raw UID2 と salt bucket IDs にマッピングします。このエンドポイントを使用して、オプトアウト情報の更新をチェックすることもできます
+
+Used by: このエンドポイントは、主に広告主やデータプロバイダーが使用します。詳細は [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) を参照してください。
+
+UID2 の Opt-Out ワークフローとユーザーが Opt-Out する方法の詳細は、[User Opt-Out](../getting-started/gs-opt-out.md) を参照してください。
+
+## Batch Size and Request Parallelization Requirements
+
+知っておくべきことは以下のとおりです:
+
+- リクエストの最大サイズは 1MB です。
+- 大量のメールアドレス、電話番号、またはそれぞれのハッシュをマップするには、1 バッチあたり最大 5,000 アイテムのバッチサイズで、それらを *連続した* バッチで送信してください。
+- Private Operator を使用している場合を除き、バッチを並行して送信しないでください。つまり、単一の HTTP 接続を使用して、[directly identifying information (DII)](../ref-info/glossary-uid.md#gl-dii) を連続してマッピングしてください。
+- メールアドレス、電話番号、またはそれぞれのハッシュのマッピングを必ず保存してください。 マッピングを保存しないと、数百万のメールアドレスや電話番号をマッピングする必要がある場合に、処理時間が大幅に増加する可能性があります。しかし、実際に更新が必要なマッピングのみを再計算することで、毎日更新が必要な raw UID2 の数は約 1/365 となり、総処理時間を短縮できます。[Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) と [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers) も参照してください。
+
+## Request Format
+
+`POST '{environment}/v2/identity/map'`
+
+認証の詳細は、 [Authentication and Authorization](../getting-started/gs-auth.md) を参照してください。
+
+:::important
+すべてのリクエストを秘密鍵で暗号化する必要があります。詳細といくつかのプログラミング言語でのコードの例は、[リクエストの暗号化とレスポンスの復号化](../getting-started/gs-encryption-decryption.md) を参照してください。
+:::
+
+### Path Parameters
+
+| Path Parameter | Data Type | Attribute | Description |
+| :--- | :--- | :--- | :--- |
+| `{environment}` | string | 必須 | テスト (インテグレーション) 環境: `https://operator-integ.uidapi.com` 本番環境: `https://prod.uidapi.com` リージョンごとのオペレーターを含む全リストは [Environments](../getting-started/gs-environments.md) を参照してください。 |
+
+:::note
+インテグレーション環境と本番環境では、異なる API Key が必要です。各環境の認証情報を取得する方法については、[Getting Your Credentials](../getting-started/gs-credentials.md#getting-your-credentials) を参照してください。
+:::
+
+### Unencrypted JSON Body Parameters
+
+:::important
+リクエストを暗号化するときは、以下の 4 つの条件パラメータのうち、**1つ** だけをリクエストの JSON ボディにキーと値のペアとして含める必要がります。
+:::
+
+| Body Parameter | Data Type | Attribute | Description |
+| :--- | :--- | :--- | :--- |
+| `email` | string array | 条件付きで必要 | マッピングするメールアドレスのリストです。 |
+| `email_hash` | string array | 条件付きで必要 | マッピングする [SHA-256 ハッシュし、Base64 エンコード](../getting-started/gs-normalization-encoding.md#email-address-normalization) した [正規化](../getting-started/gs-normalization-encoding.md#email-address-hash-encoding) 済みメールアドレスのリストです。 |
+| `phone` | string array | 条件付きで必要 | マッピングする [正規化](../getting-started/gs-normalization-encoding.md#phone-number-normalization) 済み電話番号のリストです。 |
+| `phone_hash` | string array | 条件付きで必要 | マッピングする [SHA-256 ハッシュし、Base64 エンコード](../getting-started/gs-normalization-encoding.md#phone-number-hash-encoding) した [正規化](../getting-started/gs-normalization-encoding.md#phone-number-normalization) 済み電話番号のリストです。 |
+
+### Request Examples
+
+以下は、各パラメータの暗号化されていない JSON リクエストボディの例です。このうちの 1 つを、`POST /identity/map` エンドポイントへのリクエストに含める必要があります:
+
+```json
+{
+ "email": [
+ "user@example.com",
+ "user2@example.com"
+ ]
+}
+```
+```json
+{
+ "email_hash": [
+ "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
+ "KzsrnOhCq4tqbGFMsflgS7ig1QLRr0nFJrcrEIlOlbU="
+ ]
+}
+```
+```json
+{
+ "phone": [
+ "+12345678901",
+ "+441234567890"
+ ]
+}
+```
+```json
+{
+ "phone_hash": [
+ "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ="
+ ]
+}
+```
+
+以下は、電話番号に対する `POST /identity/map` エンドポイントへの暗号化リクエストの例です:
+
+```sh
+echo '{"phone": ["+12345678901", "+441234567890"]}' | python3 uid2_request.py https://prod.uidapi.com/v2/identity/map [Your-Client-API-Key] [Your-Client-Secret]
+```
+
+詳細といくつかのプログラミング言語でのコードの例は、[リクエストの暗号化とレスポンスの復号化](../getting-started/gs-encryption-decryption.md) を参照してください。
+
+## Decrypted JSON Response Format
+
+:::note
+レスポンスは、HTTP ステータスコードが 200 の場合のみ暗号化されます。それ以外の場合、レスポンスは暗号化されません。
+:::
+
+復号化に成功すると、指定したメールアドレス、電話番号、またはそれぞれのハッシュに対する raw UID2 とソルトバケット ID が返されます。
+
+```json
+{
+ "body": {
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ },
+ {
+ "identifier": "Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ=",
+ "advertising_id": "IbW4n6LIvtDj/8fCESlU0QG9K/fH63UdcTkJpAG8fIQ=",
+ "bucket_id": "ad1ANEmVZ"
+ }
+ ]
+ },
+ "status": "success"
+}
+```
+
+一部の識別子が無効と判断された場合、それらの識別子は "unmapped" リストとしてレスポンスに含まれる。この場合でも、レスポンスステータスは "success" となります。すべての識別子がマッピングされた場合、"unmapped"リストはレスポンスに含まれません。
+
+```json
+{
+ "body": {
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ }
+ ],
+ "unmapped": [
+ {
+ "identifier": "some@malformed@email@hash",
+ "reason": "invalid identifier"
+ }
+ ]
+ },
+ "status": "success"
+}
+```
+
+一部の識別子が UID2 エコシステムからオプトアウトしている場合、オプトアウトした識別子は、見つかった無効な識別子とともに "unmapped" リストに移動されます。この場合でも、レスポンスステータスは "success" です。
+
+```json
+{
+ "body": {
+ "mapped": [
+ {
+ "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "bucket_id": "a30od4mNRd"
+ }
+ ],
+ "unmapped": [
+ {
+ "identifier": "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
+ "reason": "optout"
+ }
+ ]
+ },
+ "status": "success"
+}
+```
+
+### Response Body Properties
+
+レスポンスボディには、次の表に示すプロパティが含まれます。
+
+| Property | Data Type | Description |
+| :--- | :--- | :--- |
+| `identifier` | string | リクエストボディで指定されたメールアドレス、電話番号、またはそれぞれのハッシュです。 |
+| `advertising_id` | string | 対応する Advertising ID (raw UID2) です。 |
+| `bucket_id` | string | raw UID2 の生成に使用したソルトバケットの ID です。 |
+
+### Response Status Codes
+
+次の表は、`status` プロパティの値と、それに対応する HTTP ステータスコードの一覧です。
+
+| Status | HTTP Status Code | Description |
+| :--- | :--- | :--- |
+| `success` | 200 | リクエストは成功しました。レスポンスは暗号化されています。 |
+| `client_error` | 400 | リクエストに不足している、または無効なパラメータがありました。 |
+| `unauthorized` | 401 | クエストにベアラートークンが含まれていない、無効なベアラートークンが含まれている、またはリクエストされた操作を実行するのに許可されていないベアラートークンが含まれていた。 |
+
+`status` の値が `success` 以外であれば、`message` フィールドにその問題に関する追加情報が表示されます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map.md b/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map.md
index 3624bb8d2..5fe824ae8 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map.md
@@ -8,193 +8,302 @@ displayed_sidebar: docs
import Link from '@docusaurus/Link';
+:::note
+このページには、近日中に翻訳される新しいコンテンツが含まれています。
+:::
+
# POST /identity/map
-複数のメールアドレス、電話番号、またはそれぞれのハッシュを、raw UID2 と salt bucket IDs にマッピングします。このエンドポイントを使用して、オプトアウト情報の更新をチェックすることもできます
+Maps multiple email addresses, phone numbers, or their respective hashes to their raw UID2s. You can also use this endpoint to check for updates to opt-out information, check when a raw UID2 can be refreshed, or view the previous UID2 if the current UID2 is less than 90 days old.
+
+Used by: This endpoint is used mainly by advertisers and data providers. For details, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
+
+For details about the UID2 opt-out workflow and how users can opt out, see [User Opt-Out](../getting-started/gs-opt-out.md).
-Used by: このエンドポイントは、主に広告主やデータプロバイダーが使用します。詳細は [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) を参照してください。
+## Version
-UID2 の Opt-Out ワークフローとユーザーが Opt-Out する方法の詳細は、[User Opt-Out](../getting-started/gs-opt-out.md) を参照してください。
+This documentation is for the latest version of this endpoint, version 3.
+
+If needed, documentation is also available for the previous version: see [POST /identity/map (v2)](post-identity-map-v2.md).
## Batch Size and Request Parallelization Requirements
-知っておくべきことは以下のとおりです:
+Here's what you need to know:
-- リクエストの最大サイズは 1MB です。
-- 大量のメールアドレス、電話番号、またはそれぞれのハッシュをマップするには、1 バッチあたり最大 5,000 アイテムのバッチサイズで、それらを *連続した* バッチで送信してください。
-- Private Operator を使用している場合を除き、バッチを並行して送信しないでください。つまり、単一の HTTP 接続を使用して、[directly identifying information (DII)](../ref-info/glossary-uid.md#gl-dii) を連続してマッピングしてください。
-- メールアドレス、電話番号、またはそれぞれのハッシュのマッピングを必ず保存してください。 マッピングを保存しないと、数百万のメールアドレスや電話番号をマッピングする必要がある場合に、処理時間が大幅に増加する可能性があります。しかし、実際に更新が必要なマッピングのみを再計算することで、毎日更新が必要な raw UID2 の数は約 1/365 となり、総処理時間を短縮できます。[Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) と [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers) も参照してください。
+- The maximum request size is 1MB.
+- To map a large number of email addresses, phone numbers, or their respective hashes, send them in *sequential* batches with a maximum batch size of 5,000 items per batch.
+- Unless you are using a Private Operator, do not send batches in parallel. In other words, use a single HTTP connection and send batches of hashed or unhashed directly identifying information (DII) values consecutively, without creating multiple parallel connections.
+- Be sure to store mappings of email addresses, phone numbers, or their respective hashes. Not storing mappings could increase processing time drastically when you have to map millions of email addresses or phone numbers. Recalculating only those mappings that actually need to be updated, however, reduces the total processing time because only about 1/365th of UID2s need to be updated daily. See also [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md) and [FAQs for Advertisers and Data Providers](../getting-started/gs-faqs.md#faqs-for-advertisers-and-data-providers).
## Request Format
-`POST '{environment}/v2/identity/map'`
+`POST '{environment}/v3/identity/map'`
-認証の詳細は、 [Authentication and Authorization](../getting-started/gs-auth.md) を参照してください。
+For authentication details, see [Authentication and Authorization](../getting-started/gs-auth.md).
:::important
-すべてのリクエストを秘密鍵で暗号化する必要があります。詳細といくつかのプログラミング言語でのコードの例は、[リクエストの暗号化とレスポンスの復号化](../getting-started/gs-encryption-decryption.md) を参照してください。
+You must encrypt all requests using your secret. For details, and code examples in different programming languages, see [Encrypting Requests and Decrypting Responses](../getting-started/gs-encryption-decryption.md).
:::
### Path Parameters
| Path Parameter | Data Type | Attribute | Description |
| :--- | :--- | :--- | :--- |
-| `{environment}` | string | 必須 | テスト (インテグレーション) 環境: `https://operator-integ.uidapi.com` 本番環境: `https://prod.uidapi.com` リージョンごとのオペレーターを含む全リストは [Environments](../getting-started/gs-environments.md) を参照してください。 |
+| `{environment}` | string | Required | Testing (integration) environment: `https://operator-integ.uidapi.com` Production environment: The best choice depends on where your users are based. For information about how to choose the best URL for your use case, and a full list of valid base URLs, see [Environments](../getting-started/gs-environments.md). |
:::note
-インテグレーション環境と本番環境では、異なる API Key が必要です。各環境の認証情報を取得する方法については、[Getting Your Credentials](../getting-started/gs-credentials.md#getting-your-credentials) を参照してください。
+The integration environment and the production environment require different API keys. For information about getting credentials for each environment, see [Getting Your Credentials](../getting-started/gs-credentials.md#getting-your-credentials).
:::
### Unencrypted JSON Body Parameters
:::important
-リクエストを暗号化するときは、以下の 4 つの条件パラメータのうち、**1つ** だけをリクエストの JSON ボディにキーと値のペアとして含める必要がります。
+Include one or more of the following four parameters as key-value pairs in the JSON body of the request when encrypting it.
:::
-| Body Parameter | Data Type | Attribute | Description |
-| :--- | :--- | :--- | :--- |
-| `email` | string array | 条件付きで必要 | マッピングするメールアドレスのリストです。 |
-| `email_hash` | string array | 条件付きで必要 | マッピングする [SHA-256 ハッシュし、Base64 エンコード](../getting-started/gs-normalization-encoding.md#email-address-normalization) した [正規化](../getting-started/gs-normalization-encoding.md#email-address-hash-encoding) 済みメールアドレスのリストです。 |
-| `phone` | string array | 条件付きで必要 | マッピングする [正規化](../getting-started/gs-normalization-encoding.md#phone-number-normalization) 済み電話番号のリストです。 |
-| `phone_hash` | string array | 条件付きで必要 | マッピングする [SHA-256 ハッシュし、Base64 エンコード](../getting-started/gs-normalization-encoding.md#phone-number-hash-encoding) した [正規化](../getting-started/gs-normalization-encoding.md#phone-number-normalization) 済み電話番号のリストです。 |
+| Body Parameter | Data Type | Attribute | Description |
+|:---------------|:----------------------------|:-----------------------| :--- |
+| `email` | string array | Conditionally Required | The list of email addresses to be mapped. |
+| `email_hash` | string array | Conditionally Required | The list of [Base64-encoded SHA-256](../getting-started/gs-normalization-encoding.md#email-address-hash-encoding) hashes of [normalized](../getting-started/gs-normalization-encoding.md#email-address-normalization) email addresses to be mapped. |
+| `phone` | string array | Conditionally Required | The list of [normalized](../getting-started/gs-normalization-encoding.md#phone-number-normalization) phone numbers to be mapped. |
+| `phone_hash` | string array | Conditionally Required | The list of [Base64-encoded SHA-256](../getting-started/gs-normalization-encoding.md#phone-number-hash-encoding) hashes of [normalized](../getting-started/gs-normalization-encoding.md#phone-number-normalization) phone numbers to be mapped. |
+
### Request Examples
-以下は、各パラメータの暗号化されていない JSON リクエストボディの例です。このうちの 1 つを、`POST /identity/map` エンドポイントへのリクエストに含める必要があります:
+The following are unencrypted JSON request body examples to the `POST /identity/map` endpoint:
```json
{
- "email": [
- "user@example.com",
- "user2@example.com"
- ]
-}
-```
-```json
-{
- "email_hash": [
- "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
- "KzsrnOhCq4tqbGFMsflgS7ig1QLRr0nFJrcrEIlOlbU="
- ]
-}
-```
-```json
-{
- "phone": [
+ "email":[
+ "user@example.com",
+ "user2@example.com"
+ ],
+ "phone":[
"+12345678901",
"+441234567890"
- ]
+ ]
}
```
+
```json
{
- "phone_hash": [
+ "email_hash":[
+ "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
+ "KzsrnOhCq4tqbGFMsflgS7ig1QLRr0nFJrcrEIlOlbU="
+ ],
+ "phone_hash":[
"EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
"Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ="
- ]
+ ]
}
```
-以下は、電話番号に対する `POST /identity/map` エンドポイントへの暗号化リクエストの例です:
+Here's an encrypted request example to the `POST /identity/map` endpoint for phone numbers:
```sh
-echo '{"phone": ["+12345678901", "+441234567890"]}' | python3 uid2_request.py https://prod.uidapi.com/v2/identity/map [Your-Client-API-Key] [Your-Client-Secret]
+echo '{"phone": ["+12345678901", "+441234567890"]}' | python3 uid2_request.py https://prod.uidapi.com/v3/identity/map [YOUR_CLIENT_API_KEY] [YOUR_CLIENT_SECRET]
```
-詳細といくつかのプログラミング言語でのコードの例は、[リクエストの暗号化とレスポンスの復号化](../getting-started/gs-encryption-decryption.md) を参照してください。
+For details, and code examples in different programming languages, see [Encrypting Requests and Decrypting Responses](../getting-started/gs-encryption-decryption.md).
## Decrypted JSON Response Format
:::note
-レスポンスは、HTTP ステータスコードが 200 の場合のみ暗号化されます。それ以外の場合、レスポンスは暗号化されません。
+The response is encrypted only if the HTTP status code is 200. Otherwise, the response is not encrypted.
:::
-復号化に成功すると、指定したメールアドレス、電話番号、またはそれぞれのハッシュに対する raw UID2 とソルトバケット ID が返されます。
+A successful decrypted response returns the current raw UID2s, previous raw UID2s, and refresh timestamps for the specified email addresses, phone numbers, or their respective hashes.
-```json
-{
- "body": {
- "mapped": [
- {
- "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
- "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
- "bucket_id": "a30od4mNRd"
- },
- {
- "identifier": "Rx8SW4ZyKqbPypXmswDNuq0SPxStFXBTG/yvPns/2NQ=",
- "advertising_id": "IbW4n6LIvtDj/8fCESlU0QG9K/fH63UdcTkJpAG8fIQ=",
- "bucket_id": "ad1ANEmVZ"
- }
- ]
- },
- "status": "success"
-}
-```
+The response arrays preserve the order of input arrays. Each element in the response array maps directly to the element at the same index in the corresponding request array. This ensures that you can reliably associate results with their corresponding inputs based on array position.
+
+Input values that cannot be mapped to a raw UID2 are mapped to an error object with the reason for unsuccessful mapping. An unsuccessful mapping occurs if the DII is invalid or has been opted out from the UID2 ecosystem. In these cases, the response status is `success` but no raw UID2 is returned.
+
+The following example shows the input and corresponding response.
-一部の識別子が無効と判断された場合、それらの識別子は "unmapped" リストとしてレスポンスに含まれる。この場合でも、レスポンスステータスは "success" となります。すべての識別子がマッピングされた場合、"unmapped"リストはレスポンスに含まれません。
+Input:
```json
{
- "body": {
- "mapped": [
- {
- "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
- "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
- "bucket_id": "a30od4mNRd"
- }
- ],
- "unmapped": [
- {
- "identifier": "some@malformed@email@hash",
- "reason": "invalid identifier"
- }
+ "email": [
+ "user@example.com", // Corresponding UID2 rotated in the last 90 days
+ "user2@example.com", // Corresponding UID2 rotated more than 90 days ago
+ "invalid email string", // Invalid identifier
+ "optout@example.com" // DII is opted out
]
- },
- "status": "success"
}
```
-一部の識別子が UID2 エコシステムからオプトアウトしている場合、オプトアウトした識別子は、見つかった無効な識別子とともに "unmapped" リストに移動されます。この場合でも、レスポンスステータスは "success" です。
+Response:
```json
{
- "body": {
- "mapped": [
- {
- "identifier": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
- "advertising_id": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
- "bucket_id": "a30od4mNRd"
- }
- ],
- "unmapped": [
- {
- "identifier": "tMmiiTI7IaAcPpQPFQ65uMVCWH8av9jw4cwf/F5HVRQ=",
- "reason": "optout"
- }
- ]
- },
- "status": "success"
+ "body":{
+ "email": [
+ {
+ "u": "AdvIvSiaum0P5s3X/7X8h8sz+OhF2IG8DNbEnkWSbYM=",
+ "p": "EObwtHBUqDNZR33LNSMdtt5cafsYFuGmuY4ZLenlue4=",
+ "r": 1735689600000
+ },
+ {
+ "u": "IbW4n6LIvtDj/8fCESlU0QG9K/fH63UdcTkJpAG8fIQ=",
+ "p": null,
+ "r": 1735862400000
+ },
+ { "e": "invalid identifier" },
+ { "e": "optout" }
+ ],
+ "email_hash": [],
+ "phone": [],
+ "phone_hash": []
+ },
+ "status": "success"
}
```
### Response Body Properties
-レスポンスボディには、次の表に示すプロパティが含まれます。
+The response body includes one or more of the properties shown in the following table.
-| Property | Data Type | Description |
-| :--- | :--- | :--- |
-| `identifier` | string | リクエストボディで指定されたメールアドレス、電話番号、またはそれぞれのハッシュです。 |
-| `advertising_id` | string | 対応する Advertising ID (raw UID2) です。 |
-| `bucket_id` | string | raw UID2 の生成に使用したソルトバケットの ID です。 |
+| Body Parameter | Data Type | Description |
+|:---------------|:----------------------------|:------------------------------------------------------------------------------------------------|
+| `email` | array of mapped DII objects | The list of mapped DII objects corresponding to the list of emails in the request. |
+| `email_hash` | array of mapped DII objects | The list of mapped DII objects corresponding to the list of email hashes in the request. |
+| `phone` | array of mapped DII objects | The list of mapped DII objects corresponding to the list of phone numbers in the request. |
+| `phone_hash` | array of mapped DII objects | The list of mapped DII objects corresponding to the list of phone number hashes in the request. |
+
+
+For successfully mapped DII, the mapped object includes the properties shown in the following table.
+
+| Property | Data Type | Description |
+|:---------|:-----------|:--------------------------------------------------------------------------------------------------------------------------------------|
+| `u` | string | The raw UID2 corresponding to the email or phone number provided in the request. |
+| `p` | string | One of the following:
If the current raw UID2 has been rotated in the last 90 days: the previous value.
If the current raw UID2 is older than 90 days: `null`.
|
+| `r` | number | The Unix timestamp (in milliseconds) that indicates when the raw UID2 might be refreshed. The raw UID2 is guaranteed to be valid until this timestamp. |
+
+For unsuccessfully mapped input values, the mapped object includes the properties shown in the following table.
+
+| Property | Data Type | Description |
+|:---------|:----------|:-----------------------------------------------------------------------------------------------------------------|
+| `e` | string | The reason for being unable to map the DII to a raw UID2. One of two possible values: