Why API Versioning Matters

API versioning allows your platform to evolve without breaking existing integrations. As APIs grow, changes to request formats, response structures, or business logic are inevitable. Versioning ensures that developers can continue using stable APIs while migrating to newer versions at their own pace.

A clear versioning strategy improves developer trust, reduces support overhead, and enables long-term platform scalability.

The Trident API Version Pipeline

Trident APIs does not use URI-based versioning (there is no /v1/ in any path). Instead, each contract is published to this portal under one of three named versions, matching the stage it has reached:

• beta — early-access changes, published for review before they progress further. Corresponds to the sandbox environment.
• stable — the validated contract used to develop and confirm integrations. Corresponds to the preprod environment.
• live — the contract currently running in production.

A change typically progresses beta → stable → live as it is validated at each stage. You do not choose an environment yourself — your API key determines which environment your traffic is routed to, and stable/live normally carry the same contract. Occasional short-lived differences (for example, a hotfix reaching live before stable) are recorded in the Release Notes, which show rollout status per version.

When to Introduce a New Version

Not every change requires a new version. A new API version is only created when a breaking change is unavoidable.

Common breaking changes include:

• Removing or renaming request fields
• Changing response structures or data types
• Modifying endpoint behavior
• Changing authentication or authorization rules

Backward-compatible changes, such as adding optional fields, are released directly through the beta → stable → live pipeline and recorded in the Trident API Release Notes — they do not require a new version.

Recommended Integration Strategy

Your API key automatically routes your traffic to the correct environment — integrate once, and let the platform handle routing. Review beta only to preview upcoming changes before they progress to stable. Check the release notes before each deployment to confirm whether a change affects your integration, and whether it has reached the tier your key is routed to.