Versioning, Sandbox and Support

Additive changes ship in v1 without notice, breaking changes become v2, and the sandbox has its own base URL and keys.

Versioning

The version is the path segment: /api/v1/….

Additive changes ship in v1 without notice. New optional request fields, new response keys, new endpoints, longer field limits, more values in an enum. Build your client to ignore keys it does not know.

Breaking changes become v2. Removing or renaming a field, changing a type, tightening a required field, changing a status code. When that happens /api/v1 keeps running through a published deprecation window, and the changelog says when it ends.

Every change, additive or not, gets a dated line in the changelog. The OpenAPI spec is generated from TrackFlo's code on every release, so the reference here is never ahead of or behind what the API accepts.

One planned change

Field validation is in a warn-only period. A body with an unknown key or a wrong type is accepted today and logged on TrackFlo's side. Shortly it will be rejected with 400 and the offending field named in error. The reference already reflects the strict behavior: send only the fields it lists, typed as shown.

Sandbox

TrackFlo runs a separate development environment with its own base URL and its own keys. Ask for a sandbox key at onboarding, point your integration there first, and switch the base URL and key to production when you are ready. Sandbox data is not visible to production users.

Support

• Integration questions and key requests: your TrackFlo contact.

• A 500: retry with backoff; if it persists, send the error_id from the response body.

• A wrong or missing field on a load: check the request body you sent against the reference first; TrackFlo stores what it receives.