> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/classic-tokenization/get-started/api-basics/connectivity.md).
# Connectivity
All Thales APIs require **mutual TLS (mTLS)** authentication. This applies to both inbound and outbound APIs.
TLS setup is the first integration step. Complete it before configuring any Thales services. The Tokenization Service uses a single endpoint per environment for all its APIs.
As an API consumer, you are a **customer**. You have a **customer identifier** in the Tokenization Service. TLS connectivity is set up per customer identifier.
TLS connectivity must be established explicitly for each isolated environment:
* Pre-Production
* Production
mTLS connectivity overview between the issuer backend and Thales TSH.
### Inbound flow (issuer backend → Thales TSH)
Once established, the TLS connection is used for all APIs. The endpoint depends on the Thales service you are calling.
Your customer client certificate (self-signed) must be endorsed (certificate pinning) in Thales backend. This endorsement is done through the Thales portal.
General requirements:
1. Mutual Authentication
2. TLS 1.2 (or higher)
3. Over the internet (no IP whitelisting)
4. Thales server CA : Digicert SHA2 High Assurance server CA
5. Customer client certificate must be a self-signed certificate with following requirement (see below)
Self-signed certificate requirements:
1. Expiry date 2 years maximum
2. Algorithm: elliptic curve with key size 256-bits or key size 384-bits or RSA 2048 bits algorithm sha256. Elliptic curve is preferred to RSA. Supported curve are prime256v1 and secp384r1.
3. Common Name : format and value is enforced and checked by Thales, the value that you should use (per environment) will be provided to you within the D1 Portal.
{% hint style="warning" %}
The **issuer backend** must always resolve the TSH domain name and its subdomains using DNS.
Thales TSH does not support long-term static IP addresses. Do not configure, hardcode, or cache TSH IP addresses longer than the DNS time-to-live (TTL).
{% endhint %}
### Outbound flow (Thales TSH → issuer backend)
General requirements:
1. Mutual authentication.
2. TLS 1.2 or later.
3. Your server must listen on port 443 (preferred) or 8443.
4. Over the public internet (no IP whitelisting).
5. You must trust Thales Client CA to authenticate our client certificate. Our Client CA is available for download from our D1 Portal for Issuer.
6. Thales D1 must trust your server certificate, for this you must provide your server CA Chain to be endorse through our D1 Portal for Issuer.
Trust only the Thales client CA, and do not pin the client certificate. Thales client certificates are signed by the Thales client CA. Thales may rotate its client certificate at any time before expiration, without notice.
Certificate exchange is managed through the TSH portal as follows:
Certificate exchange flow in the TSH portal.
Use the credentials provided by the Thales delivery team to access the portal: [TSH portal](https://portal.dbp.thalescloud.io/app-tsh-onboarding/index.html#/)
This table summarizes the assets exchanged through the portal for TLS setup:
| ASSET | DESCRIPTION |
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TSH\_TLS\_SERVER\_CERTIFICATE\_CHAIN |
Thales TSH server certificate chain. Trust it to establish a TLS connection from the issuer backend to Thales TSH.
|
| TSH\_TLS\_CLIENT\_CERTIFICATE |
Thales TSH client certificate. Trust it to accept TLS connections from Thales TSH to the issuer backend.
|
| TSH\_INBOUND\_HOST |
Thales TSH hostname to call. Use it with the API base path.
|
| CUSTOMER\_TLS\_SERVER\_CERTIFICATE\_CHAIN |
Your server certificate chain. Thales TSH uses it to trust your server certificate and establish a TLS connection to the issuer backend.
|
| ISSUER\_HOST |
Issuer backend hostname. Thales TSH uses it with the API base path to call the issuer backend.
|
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.payments.thalescloud.io/classic-tokenization/get-started/api-basics/connectivity.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.