API change policy

Thales evolves the D1 API while keeping integrations stable.

Use this page to design your issuer backend to tolerate API changes.

Backward compatibility rules

Design your issuer backend to tolerate API changes and extensions.

Your issuer backend must be resilient to these changes:

Avoid strict validation in your issuer backend.

Strict validation rejects unknown fields.

• Thales may add optional parameters in HTTP headers, URLs, and JSON bodies.

• Error message strings may change between releases. Use them only for troubleshooting.

• Parameters sent or returned by D1 backend may evolve from optional to required.

• Parameters sent or returned by the issuer backend may evolve from required to optional.

• Parameter order is not fixed.

• New values may be added to existing enumeration parameters.

• New API operations may be added (new paths and/or HTTP methods).

• New HTTP response status codes may be added.

Deprecations and end of life

Thales notifies the issuer at least 9 months before end of life.

This applies to any API parameter or API operation.

After the deprecation period ends, do not use deprecated parameters or operations in:

• Production

• PreProd

Thales may shorten the deprecation period when required due to:

• A significant security risk

• A substantial economic or material technical impact

• Applicable law or payment network requirements

Deprecated parameters and operations are marked as deprecated in the technical documentation.