Revert (v3)

vishalegbert-ttd · vishalegbert-ttd · commit 18af9b132a1d · 2025-06-20T13:20:19.000+10:00
diff --git a/docs/endpoints/post-identity-map-v2.md b/docs/endpoints/post-identity-map-v2.md
@@ -17,7 +17,7 @@ For details about the UID2 opt-out workflow and how users can opt out, see [User
 
 ## Version
 
-This documentation is for earlier version 2 of this endpoint. For documentation for the latest version 3 of this endpoint, see: [POST /identity/map (v3)](post-identity-map-v3.md).
+This documentation is for earlier version 2 of this endpoint. For documentation for the latest version 3 of this endpoint, see: [POST /identity/map](post-identity-map.md).
 
 ## Batch Size and Request Parallelization Requirements
 
diff --git a/docs/endpoints/post-identity-map.md b/docs/endpoints/post-identity-map.md
@@ -1,5 +1,5 @@
 ---
-title: POST /identity/map (v3)
+title: POST /identity/map
 description: Maps DII to UID2s.
 hide_table_of_contents: false
 sidebar_position: 08
@@ -8,7 +8,7 @@ displayed_sidebar: docs
 
 import Link from '@docusaurus/Link';
 
-# POST /identity/map (v3)
+# POST /identity/map
 
 Maps multiple email addresses, phone numbers, or their respective hashes to their UID2s. You can also use this endpoint to check for updates to opt-out information, check when a UID2 can be refreshed, or view the previous UID2 if the current UID2 is less than 90 days old.
 
diff --git a/docs/endpoints/summary-endpoints.md b/docs/endpoints/summary-endpoints.md
@@ -34,7 +34,7 @@ Calling the /identity/buckets endpoint is no longer necessary when calling the l
 
 | Endpoint | Description | Request Encryption | Response Decryption |
 | :--- | :--- | :--- | :--- |
-| [POST&nbsp;/identity/map (v3)](post-identity-map-v3.md) | Maps UID2s, previous UID2s and refresh timestamps for one or more email addresses, phone numbers, or their respective hashes.  | Required | Required |
+| [POST&nbsp;/identity/map](post-identity-map.md) | Maps UID2s, previous UID2s and refresh timestamps for one or more email addresses, phone numbers, or their respective hashes.  | Required | Required |
 
 ### Earlier V2 Identity Map Endpoints
 
diff --git a/docs/getting-started/gs-credentials.md b/docs/getting-started/gs-credentials.md
@@ -22,7 +22,7 @@ Each UID2 <a href="../overviews/participants-overview#uid2-external-participants
 If you're using the integration <Link href="../ref-info/glossary-uid#gl-environment">environment</Link> as well as the production environment, you'll get a separate set of credentials for each environment. See [Getting Your Credentials](#getting-your-credentials).
 
 In addition, in some cases, we recommend, but do not require, that you have a different set of credentials for a different scenario. For example:
-- If you're a publisher who generates UID2 tokens (via [POST /token/generate](../endpoints/post-token-generate.md) or in some other way), but you also create/map raw UID2s on your own behalf (see [POST /identity/map (v3)](../endpoints/post-identity-map-v3.md)), you might have separate credentials for each of these activities.
+- If you're a publisher who generates UID2 tokens (via [POST /token/generate](../endpoints/post-token-generate.md) or in some other way), but you also create/map raw UID2s on your own behalf (see [POST /identity/map)](../endpoints/post-identity-map.md)), you might have separate credentials for each of these activities.
 - If you're an advertiser, in a scenario where you allow multiple service providers to operate using your advertiser keys, you might choose to have separate credentials for each service provider.
 
 ## Getting Your Credentials
diff --git a/docs/getting-started/gs-faqs.md b/docs/getting-started/gs-faqs.md
@@ -38,7 +38,7 @@ Yes. Through the [Transparency and Control Portal](https://www.transparentadvert
 
 No. None of the components of the <Link href="../ref-info/glossary-uid#gl-uid2-service">UID2 service</Link> store any DII.
 
-In addition, in almost all cases, UID2 doesn't store any values at all once the [POST&nbsp;/token/generate](../endpoints/post-token-generate.md), [POST&nbsp;/token/refresh](../endpoints/post-token-refresh.md), or [POST&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) call is complete. A necessary exception is the case where a user has opted out. In this scenario, UID2 stores a hashed, opaque value to indicate the opted-out user. The stored value cannot be reverse engineered back to the original value of the DII, but can be used to identify future requests for a UID2 generated from the same DII, which are therefore denied.
+In addition, in almost all cases, UID2 doesn't store any values at all once the [POST&nbsp;/token/generate](../endpoints/post-token-generate.md), [POST&nbsp;/token/refresh](../endpoints/post-token-refresh.md), or [POST&nbsp;/identity/map](../endpoints/post-identity-map.md) call is complete. A necessary exception is the case where a user has opted out. In this scenario, UID2 stores a hashed, opaque value to indicate the opted-out user. The stored value cannot be reverse engineered back to the original value of the DII, but can be used to identify future requests for a UID2 generated from the same DII, which are therefore denied.
 
 #### Does UID2 allow the processing of HIPAA-regulated data?
 
@@ -203,23 +203,23 @@ Unless you are using a <Link href="../ref-info/glossary-uid#gl-private-operator"
 
 #### How should I handle user opt-outs?
 
-When a user opts out of UID2-based targeted advertising through the [Transparency and Control Portal](https://www.transparentadvertising.com/), the opt-out signal is sent to DSPs and publishers, who handle opt-outs at bid time. We recommend that advertisers and data providers regularly check whether a user has opted out, via the [POST /identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint.
+When a user opts out of UID2-based targeted advertising through the [Transparency and Control Portal](https://www.transparentadvertising.com/), the opt-out signal is sent to DSPs and publishers, who handle opt-outs at bid time. We recommend that advertisers and data providers regularly check whether a user has opted out, via the [POST /identity/map](../endpoints/post-identity-map.md) endpoint.
 
 Advertisers and data providers can also check the opt-out status of raw UID2s using the [POST&nbsp;/optout/status](../endpoints/post-optout-status.md) endpoint.
 
 If a user opts out through your website, you should follow your internal procedures for handling the opt-out. For example, you might choose not to generate a UID2 for that user.
 
 #### Does the same DII always result in the same raw UID2?
 
-In general yes, the process of generating a raw UID2 from DII is the same, and results in the same value, no matter who sent the request. If two UID2 participants were to send the same email address to the [POST&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint at the same time, they would both get the same raw UID2 in response.
+In general yes, the process of generating a raw UID2 from DII is the same, and results in the same value, no matter who sent the request. If two UID2 participants were to send the same email address to the [POST&nbsp;/identity/map](../endpoints/post-identity-map.md) endpoint at the same time, they would both get the same raw UID2 in response.
 
 However, there is a variable factor, which is the secret <Link href="../ref-info/glossary-uid#gl-salt">salt</Link> 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.
 
 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*.
 
 #### If two operators process the same DII, are the results the same?
 
-Yes, if the request is for a <Link href="../ref-info/glossary-uid#gl-raw-uid2">raw UID2</Link>. As covered in the previous FAQ, [Does the same DII always result in the same raw UID2?](#does-the-same-dii-always-result-in-the-same-raw-uid2), if an advertiser or data provider sends the same DII to the UID2 Operator, by using an SDK or the [POST&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint, at the same time, the same raw UID2 is created.
+Yes, if the request is for a <Link href="../ref-info/glossary-uid#gl-raw-uid2">raw UID2</Link>. As covered in the previous FAQ, [Does the same DII always result in the same raw UID2?](#does-the-same-dii-always-result-in-the-same-raw-uid2), if an advertiser or data provider sends the same DII to the UID2 Operator, by using an SDK or the [POST&nbsp;/identity/map](../endpoints/post-identity-map.md) endpoint, at the same time, the same raw UID2 is created.
 
 The result is the same, regardless of the <Link href="../ref-info/glossary-uid#gl-operator">Operator</Link> and whether it's a Private Operator or a Public Operator.
 
diff --git a/docs/getting-started/gs-opt-out.md b/docs/getting-started/gs-opt-out.md
@@ -49,7 +49,7 @@ The following steps provide a high-level outline of the opt-out workflow intende
    | :--- | :--- | 
    | Publishers | A publisher calling  [POST&nbsp;/token/generate](../endpoints/post-token-generate.md) with the required `optout_check` parameter set to `1`, or [POST&nbsp;/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).<br/>DSPs can also check the opt-out status of raw UID2s using the [POST&nbsp;/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&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint. Another option is to check the opt-out status of raw UID2s using the [POST&nbsp;/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&nbsp;/identity/map](../endpoints/post-identity-map.md) endpoint. Another option is to check the opt-out status of raw UID2s using the [POST&nbsp;/optout/status](../endpoints/post-optout-status.md) endpoint. |
    | Sharers | UID2 sharers can check the opt-out status of raw UID2s using the [POST&nbsp;/optout/status](../endpoints/post-optout-status.md) endpoint. |
 
 This workflow allows users to opt out of personalized advertising based on their UID2 through the Transparency and Control Portal.
diff --git a/docs/getting-started/gs-permissions.md b/docs/getting-started/gs-permissions.md
@@ -26,4 +26,4 @@ The following table lists the key permissions, the types of participants that co
 | Generator | Publishers | Permission to call the [POST&nbsp;/token/generate](../endpoints/post-token-generate.md), [POST&nbsp;/token/validate](../endpoints/post-token-validate.md), and [POST&nbsp;/token/refresh](../endpoints/post-token-refresh.md) endpoints, to generate UID2 tokens from <Link href="../ref-info/glossary-uid#gl-dii">DII</Link> and to refresh them, using one of these integration methods:<ul><li>A Prebid integration</li><li>The SDK for JavaScript</li><li>An integration that directly calls the applicable API endpoints for retrieving and managing UID2 tokens.</li></ul> |
 | Bidder | DSPs | Permission to decrypt UID2 tokens coming in from the <Link href="../ref-info/glossary-uid#gl-bidstream">bidstream</Link> 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:<ul><li>Encrypt raw UID2s into UID2 tokens for sharing with another authorized sharing participant, using a UID2 SDK or Snowflake</li><li>Decrypt UID2 tokens received from another authorized sharing participant into raw UID2s.</li></ul> |
-| Mapper | Advertisers<br/>Data Providers | Permission to call the [POST&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s, previous raw UID2s and refresh timestamps. Permission to use the earlier V2 Identity Map [POST&nbsp;/identity/map (v2)](../endpoints/post-identity-map-v2.md) and [POST&nbsp;/identity/buckets](../endpoints/post-identity-buckets.md) endpoints as well. |
+| Mapper | Advertisers<br/>Data Providers | Permission to call the [POST&nbsp;/identity/map](../endpoints/post-identity-map.md) endpoint to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s, previous raw UID2s and refresh timestamps. Permission to use the earlier V2 Identity Map [POST&nbsp;/identity/map (v2)](../endpoints/post-identity-map-v2.md) and [POST&nbsp;/identity/buckets](../endpoints/post-identity-buckets.md) endpoints as well. |
diff --git a/docs/sdks/summary-sdks.md b/docs/sdks/summary-sdks.md
@@ -28,7 +28,7 @@ The following table summarizes the functionality available with each SDK.
 |Android | Client&nbsp;(Mobile) | &#8212; | &#8212; | &#9989; | &#9989; | &#8212; | &#8212; |
 |iOS | Client (Mobile) | &#8212; | &#8212; | &#9989;| &#9989; |&#8212; | &#8212; |
 
-&ast;Advertisers and Data Providers who need to generate raw UID2s from DII can also do this via Snowflake (see [Snowflake Integration Guide](../guides/integration-snowflake.md)) or by using the [POST&nbsp;/identity/map (v3)](../endpoints/post-identity-map-v3.md) endpoint.
+&ast;Advertisers and Data Providers who need to generate raw UID2s from DII can also do this via Snowflake (see [Snowflake Integration Guide](../guides/integration-snowflake.md)) or by using the [POST&nbsp;/identity/map](../endpoints/post-identity-map.md) endpoint.
 
 <!-- &#9989; = Supported | &#8212; = Not Supported -->
 
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
@@ -1,5 +1,5 @@
 ---
-title: POST /identity/map (v3)
+title: POST /identity/map
 description: Maps DII to UID2s.
 hide_table_of_contents: false
 sidebar_position: 08
diff --git a/sidebars.js b/sidebars.js
@@ -322,10 +322,10 @@ const fullSidebar = [
         'endpoints/post-identity-buckets',
         {
           type: 'category',
-          label: 'POST /identity/map (v3)',
+          label: 'POST /identity/map',
           link: {
             type: 'doc',
-            id: 'endpoints/post-identity-map-v3',
+            id: 'endpoints/post-identity-map',
           },
           collapsed: true,
           items: [
@@ -409,7 +409,7 @@ const sidebars = {
     'DSP Integrations',
     'guides/dsp-guide',
     'endpoints/post-identity-buckets',
-    'endpoints/post-identity-map-v3',
+    'endpoints/post-identity-map',
     'endpoints/post-identity-map-v2',
     'endpoints/post-optout-status'
   ),
