Skip to main content

​
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
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.

​
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 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 for updates on API changes
  • Test against the development environment when updating your integration