Updated V2/3 -> v2/3 for consistency with other docs

Author: aulme

docs/endpoints/post-identity-buckets.md

@@ -15,9 +15,9 @@ Monitors rotated <Link href="../ref-info/glossary-uid#gl-salt-bucket">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 of `POST /v3/identity/map`, v3, you don't need to use `POST /identity/buckets` at all. You only need to use it if you're using the earlier version, `POST /v2/identity/map`.
+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).
+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

docs/endpoints/post-identity-map-v2.md

@@ -20,7 +20,7 @@ For details about the UID2 opt-out workflow and how users can opt out, see [User
 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).
+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

docs/endpoints/post-identity-map.md

@@ -195,26 +195,26 @@ The following table lists the `status` property values and their HTTP status cod
 
 If the `status` value is anything other than `success`, the `message` field provides additional information about the issue.
 
-## Migration from V2 Identity Map
+## 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)
+- [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:
+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 <Link href="../ref-info/glossary-uid#gl-salt-bucket-id">salt buckets</Link> 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
+### Key Differences Between v2 and v3
 
 The following table shows key differences between the versions.
 
@@ -238,20 +238,20 @@ To upgrade from an earlier version to version 3, follow these steps:
 Update any reference to the endpoint URL so that it references the /v3/ implementation, as shown in the following example.
 
 ```python
-# Before (V2)
+# Before (v2)
 url = '/v2/identity/map'
 
-# After (V3) 
+# After (v3) 
 url = '/v3/identity/map'
 ```
 
-#### 2. Update V3 Response Parsing Logic
+#### 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
+# v2: Process mapped/unmapped objects with identifier lookup
 for item in response['body']['mapped']:
     raw_uid = item['advertising_id']
     bucket_id = item['bucket_id']
@@ -262,7 +262,7 @@ for item in response['body']['mapped']:
 
 V3 Response Parsing:
 ```python
-# V3: Process array-indexed responses
+# 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:

docs/endpoints/summary-endpoints.md

@@ -26,7 +26,7 @@ The following endpoints are for retrieving and managing UID2 tokens (identity to
 
 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)
+### 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.
 
@@ -40,7 +40,7 @@ The latest identity map integration uses the following endpoint:
 | :--- | :--- | :--- | :--- |
 | [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)
+### Earlier Identity Map Endpoints (v2)
 
 The following endpoints are part of the earlier identity map integration (version 2).  
 

docs/getting-started/gs-faqs.md

@@ -187,7 +187,7 @@ To determine whether to refresh a raw UID2:
 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 <Link href="../ref-info/glossary-uid#gl-dii">DII</Link>.
 
 :::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 after that time, the raw UID2 is refreshed.
+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 raw UID2s be refreshed for incremental updates?

docs/getting-started/gs-permissions.md

@@ -27,4 +27,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 following endpoints  to map multiple email addresses, phone numbers, or their respective hashes to their raw UID2s, previous raw UID2s, and refresh timestamps:<ul><li>[POST&nbsp;/identity/map](../endpoints/post-identity-map.md) (latest version)</li><li>The earlier (version 2) identity mapping endpoints: [POST&nbsp;/identity/map (v2)](../endpoints/post-identity-map.md) and [POST&nbsp;/identity/buckets](../endpoints/post-identity-buckets.md).</li></ul>                                                                              |
+| Mapper | Advertisers<br/>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:<ul><li>[POST&nbsp;/identity/map](../endpoints/post-identity-map.md) (latest version)</li><li>The earlier v2 identity mapping endpoints: [POST&nbsp;/identity/map (v2)](../endpoints/post-identity-map.md) and [POST&nbsp;/identity/buckets](../endpoints/post-identity-buckets.md).</li></ul>                                                                              |

docs/guides/integration-advertiser-dataprovider-endpoints.md

@@ -95,7 +95,7 @@ You could also send conversion information via API or pixels for measurement (at
 
 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.
+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. The following table shows the steps for monitoring raw UID2 refresh.
 
@@ -142,21 +142,21 @@ The following sections provide information about implementing an earlier version
 
 ### Earlier Versions: High-Level Steps
 
-At a high level, the steps for advertisers and data providers integrating with UID2 using the `POST /v2/identity/map endpoint` are the same as for the current version, as shown in the following summary of steps. However, Step 2 and Step 5 are significantly different: for details, see [Integration Diagram (V2)](#integration-diagram-v2).
+At a high level, the steps for advertisers and data providers integrating with UID2 using the `POST /v2/identity/map endpoint` are the same as for the current version, as shown in the following summary of steps. However, Step 2 and Step 5 are significantly different: for details, see [Integration Diagram (v2)](#integration-diagram-v2).
 
 1. [Generate Raw UID2s from DII](#1-generate-raw-uid2s-from-dii)
 
-2. [Store Raw UID2s and Salt Bucket IDs (V2)](#store-raw-uid2s-and-salt-bucket-ids-v2)
+2. [Store Raw UID2s and Salt Bucket IDs (v2)](#store-raw-uid2s-and-salt-bucket-ids-v2)
 
 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 (V2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2)
+5. [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2)
 
 6. [Monitor for Opt-Out Status](#6-monitor-for-opt-out-status)
 
-### Integration Diagram (V2)
+### Integration Diagram (v2)
 
 The following diagram outlines the steps that data collectors must complete to map DII to raw UID2s for audience building and targeting.
 
@@ -166,14 +166,14 @@ DII refers to a user's normalized email address or phone number, or the normaliz
 
 <!-- diagram source: resource/advertiser-flow-endpoints-v2-mermaid.md.bak -->
 
-### Store Raw UID2s and Salt Bucket IDs (V2)
+### Store Raw UID2s and Salt Bucket IDs (v2)
 
 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 (V2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
+- 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)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
 
-### Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (V2)
+### Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)
 
 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 <Link href="../ref-info/glossary-uid#gl-salt-bucket">salt bucket</Link> rotation.
 

docs/guides/integration-advertiser-dataprovider-overview.md

@@ -121,7 +121,7 @@ You could also send conversion information via API or pixels for measurement (at
 
 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.
+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:
 
@@ -173,11 +173,11 @@ At a high level, the steps for advertisers and data providers integrating with U
 
 6. [Monitor for Opt-Out Status](#6-monitor-for-opt-out-status)
 
-### Implementation Options (V2)
+### Implementation Options (v2)
 
-The implementation options that are available for advertisers and data providers are the same regardless of version. For details, see [Summary of Implementation Options](#summary-of-implementation-options). However, if you're using an implementation that uses the `POST /v2/identity/map` endpoint, Step 5 is different, as shown in [Integration Diagram (V2)](#integration-diagram-v2). For instructions for Step 5, see [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (V2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
+The implementation options that are available for advertisers and data providers are the same regardless of version. For details, see [Summary of Implementation Options](#summary-of-implementation-options). However, if you're using an implementation that uses the `POST /v2/identity/map` endpoint, Step 5 is different, as shown in [Integration Diagram (v2)](#integration-diagram-v2). For instructions for Step 5, see [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
 
-### Integration Diagram (V2)
+### Integration Diagram (v2)
 
 The following diagram outlines the steps that data collectors must complete to map DII to raw UID2s for audience building and targeting.
 
@@ -189,16 +189,16 @@ To keep your UID2-based audience information accurate and up to date, follow the
 
 <!-- diagram source: resource/advertiser-flow-overview-v2-mermaid.md.bak -->
 
-For details about the different parts of the diagram, refer to [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (V2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2) for Step 5, or [Summary of Implementation Options](#summary-of-implementation-options) for all other steps.
+For details about the different parts of the diagram, refer to [Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2) for Step 5, or [Summary of Implementation Options](#summary-of-implementation-options) for all other steps.
 
-### Store Raw UID2s and Salt Bucket IDs (V2)
+### Store Raw UID2s and Salt Bucket IDs (v2)
 
 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 (V2)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
+- 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)](#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
 
-### Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (V2)
+### Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)
 
 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 <Link href="../ref-info/glossary-uid#gl-salt-bucket">salt bucket</Link> rotation.
 
@@ -212,13 +212,13 @@ 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 (V2)](integration-advertiser-dataprovider-endpoints.md#monitor-for-salt-bucket-rotations-for-your-stored-raw-uid2s-v2).
+- 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 (V2)
+##### 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.