> ## Documentation Index
> Fetch the complete documentation index at: https://openapidocs.flexforwardship.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning

> How the Flex Forward API handles changes and backward compatibility

# Versioning

The Flex Forward API is designed for long-term stability. Changes are made carefully to avoid breaking existing integrations.

## Current version

The API is at version **1.0.0**. There is no version prefix in the URL — all endpoints are accessed directly (e.g., `POST /labels`, not `POST /v1/labels`).

## Backward compatibility

The Flex Forward team is committed to backward compatibility. Existing integrations will continue to work as the API evolves.

### Non-breaking changes

The following changes may be made without advance notice. Your integration should handle them gracefully:

* Adding new optional fields to request bodies
* Adding new fields to response bodies
* Adding new API endpoints
* Adding new enum values in response fields
* Adding new HTTP status codes for edge cases
* Improving error messages for clarity

<Note>
  Always ignore unexpected fields in API responses rather than treating them as errors. Handle unknown enum values gracefully — for example, treat an unrecognized tracking `tag` as `Unknown`. This ensures your integration is resilient to non-breaking additions.
</Note>

### Breaking changes

The following changes are considered breaking and will be communicated with advance notice:

* Removing or renaming existing fields
* Changing the data type of existing fields
* Removing API endpoints
* Changing the authentication mechanism
* Changing the meaning of existing status codes

Breaking changes will be communicated in advance through the [Changelog](/changelog) and direct notification to affected API consumers. Non-breaking improvements may be released without URL version changes while preserving backward compatibility for existing integrations.

## Integration recommendations

* Parse response bodies tolerantly — ignore unknown fields
* Do not validate responses against a strict schema that rejects new fields
* Subscribe to the [Changelog](/changelog) for updates on API changes
* Test against the [development environment](/environments) when updating your integration