# Token Requestor Identifier (TRID) API
source: https://developer.mastercard.com/token-requestor-identifier-api/documentation/index.md

## Overview {#overview}

The Mastercard Digital Enablement Service (MDES) [On-Behalf-Of (OBO) model](https://developer.mastercard.com/mdes-digital-enablement/documentation/use-cases/mdes-for-merchants-on-behalf-of-model-use-cases/) for merchants allows Payment Service Providers (PSPs) to perform tokenization and transaction activities on behalf of the merchants they represent. A PSP operating in this model is referred to as an On-Behalf-Of Token Requestor (OBOTR), and the merchant they support is described as the token requestor. To leverage the MDES tokenization service via the [Digital Enablement API](https://developer.mastercard.com/mdes-digital-enablement/documentation/api-reference/), an OBOTR must be on boarded first to obtain a Token Requestor Identifier (TRID) for each of their merchants.

The Token Requestor Identifier (TRID) API enables OBOTR(s) to on board token requestors to MDES and manage them in a quick and efficient way.

### Key benefits {#key-benefits}

* Ability to onboard and update token requestors in large batches in a short interval.
* Single interface that allows both creating and updating of token requestors.
* Seamless integration driven by a familiar API onboarding process.
* Swift identification of duplicate TRID requests.
* Elimination of any chance of manual errors.

## How it works {#how-it-works}

An OBOTR can invoke the TRID API once all the information needed for on boarding is available to them from the token requestor. This can be done after the token requestor registers with the OBOTR for their On-behalf-Of services.

TRID API allows token requestors to be on boarded in batches and returns a unique Token Requestor ID (TRID) for each token requestor successfully on boarded. The OBOTR can then use the TRID(s) obtained to call the MDES [Tokenize API](https://developer.mastercard.com/mdes-digital-enablement/documentation/api-reference/) to tokenize card credentials belonging to the token requestor's customers (cardholders).
![](https://static.developer.mastercard.com/content/token-requestor-identifier-api/uploads/TRID-MDES-Updated.png)

## When to request a TRID {#when-to-request-a-trid}

Note: Do not request a unique TRID when the merchant is a sub-merchant under a Payment Facilitator model. For more information on sub-merchants and Payment Facilitators, please contact your Mastercard representative.

The following examples illustrate how the OBOTR requests a TRID for each of their Token Domains (merchants).

### Merchants with multiple websites {#merchants-with-multiple-websites}

In this example, the OBOTR has onboarded two different merchants, 'Movie Store' and 'Sports Shop'. Entities that belong to 'Movie Store' such as moviestore.co.uk, moviestore.com, and moviestore.au should all be represented by a single TRID behind the OBOTR as they comprise a single token domain, and are therefore one consumer facing entity.

For reference, a Token Domain refers to the grouped services and contexts that directly relate to the creation, management, and searching of tokens. An appropriate consumer facing entity name for the TRID in this example would be 'Movie Store'. In the case of 'Sport Shop', they too have one TRID assigned to their one entity:
![](https://static.developer.mastercard.com/content/token-requestor-identifier-api/uploads/merchant-multisite.png)

### Merchants with regional locations {#merchants-with-regional-locations}

For merchants with multiple physical locations, the same principle applies. A single TRID should be assigned to a consumer facing entity, in this case, 'Pro Gym', as they are of the same token domain:
![](https://static.developer.mastercard.com/content/token-requestor-identifier-api/uploads/merchant-regional.png)

## Good to Know {#good-to-know}

* [Use Cases](https://developer.mastercard.com/token-requestor-identifier-api/documentation/use-cases/index.md) - Use cases currently supported by the Token Requestor Identifier (TRID) API
* [API Reference](https://developer.mastercard.com/token-requestor-identifier-api/documentation/api-reference/index.md) - Open API specification along with the list of parameters for the API
* [Code and Formats](https://developer.mastercard.com/token-requestor-identifier-api/documentation/code-and-formats/index.md) - Error codes and error responses
* [Testing](https://developer.mastercard.com/token-requestor-identifier-api/documentation/testing/index.md) - Test payloads for testing in Sandbox and Member Test Facility (MTF)
* [Support](https://developer.mastercard.com/token-requestor-identifier-api/documentation/support/index.md) - Additional information in the form of frequently asked questions and contact information for support

## Next steps {#next-steps}

Now that you have an understanding of what the service does, proceed to the [API Basics](https://developer.mastercard.com/token-requestor-identifier-api/documentation/api-basics/index.md) section for details on authentication.