API versioning

Who this is for

Integration engineers building a client, and architects assessing how change to the Quant Flow Platform API will reach their systems.

The API-Version header

Every request carries an API-Version header. It names the version of the Quant Flow API the request follows, as major.minor.patch. Send the contract version your client was tested against. Confirm supported releases and version enforcement with the deployment owner; the header alone does not prove parallel version routing.

API-Version: 1.0.0

Send the header on every request, including sign-in. Some individual service parameters are optional; keeping it explicit makes the client's contract version unambiguous.
The value has the form of three whole numbers separated by full stops.
The current version of the API, and the version the API Reference describes, is 1.0.0.

The version is not part of the URL. Paths such as /api/transactions stay the same across versions.

What a version number means

Change	Version movement
A change that breaks existing clients	New major version (for example `1.0.0` to `2.0.0`)
A change that does not break clients	Use the version published in the contract and release notes; do not infer a new minor or patch version from an individual field change.

Review the deployed release and its compatibility notes before upgrades. Pinning 1.0.0 is not a substitute for regression tests or an agreed supported-version window.

Treat these as non-breaking and build your client to tolerate them:

New optional fields in a response.
New values in an enum that the API Reference describes as open, such as failureCode on a cancelled operation, which may carry free text.
New endpoints.

Tolerate unknown optional fields. Handle unknown response enum values without crashing, while continuing to validate the request enums you send against your pinned contract. Review release notes before adopting changed behavior.

Choosing a version to send

Send the version your client was built and tested against. Pin it in configuration, not in code, so a move to a new version is a deliberate, tested change.

Worked example

Illustrative example built from the schema.

GET /api/accounts/ACC-000184-GBP/balances HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer eyJraWQiOiJ...
API-Version: 1.0.0

HTTP/1.1 200 OK
Content-Type: application/json

{
  "accountRef": "ACC-000184-GBP",
  "customerRef": "CUST-000184",
  "assetId": "GBP",
  "total": "1250.00",
  "available": "1210.00",
  "locked": "40.00",
  "asOf": "2026-08-13T11:58:04.114Z"
}

View in API Reference

Get an account's balances · GET

Errors and edge cases

Missing header. Always send the header. The public contract does not specify a single platform-wide error status or message for its omission; handle the endpoint response as an HTTP failure rather than matching a guessed message.
Unsupported or malformed version. Send a supported numeric version, not latest. Unsupported-version response details are not specified consistently across endpoints; capture the returned status and sanitised body for diagnosis.
Response version. The contract does not guarantee a response version header. Retain the version sent with each request in your own diagnostics.
Deprecation. Agree the supported-version window and upgrade notice with your platform contact. The contract does not promise a fixed support period or a universal sunset header.
Changelog. Use the release notes supplied for your deployment to plan upgrades. The public API contract does not define a separate changelog endpoint.

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Operation	Method
Submit a token operation	`POST`
Get an account's balances	`GET`