API Versioning Guide
The Firma API uses header-based versioning via theX-API-Version header. This allows you to specify which API version you want to use, with automatic deprecation warnings and a structured sunset process.
How to Specify a Version
Include theX-API-Version header in your request:
If the
X-API-Version header is omitted, the API defaults to the current stable version (currently 1).Version Lifecycle
Each API version goes through three stages:| Status | Description | Behavior |
|---|---|---|
| active | Fully supported version | Normal responses with X-API-Version header |
| deprecated | Still functional but scheduled for removal | Responses include deprecation warning headers |
| sunset | Removed from service | Returns 410 Gone error |
Response Headers
For Active Versions
For Deprecated Versions
When a version is deprecated, the following headers are included in every response:| Header | Description |
|---|---|
Deprecation | RFC 8594 compliant - Date when the version was deprecated |
Sunset | RFC 8594 compliant - Date when the version will be removed |
X-Deprecated-Message | Human-readable warning message |
Error Responses
Invalid Version Header
Unsupported Version
Sunset Version (Removed)
Breaking Changes Policy
Breaking changes are only introduced in major version increments (e.g., v1 → v2). Non-breaking changes such as new optional fields or new endpoints do not require a new version.
- The previous version is marked as deprecated
- You’ll receive warning headers for a recommended 6-month deprecation period
- After the sunset date, the old version returns
410 Gone
What Constitutes a Breaking Change?
Breaking changes include:- Removing or renaming existing fields
- Changing field types or validation rules
- Removing endpoints
- Changing authentication requirements
- Modifying rate limits significantly
- Adding new optional fields
- Adding new endpoints
- Adding new enum values (if your client handles unknown values gracefully)
- Improving error messages
Best Practices
Always check for deprecation headers
Always check for deprecation headers
Implement automated checks in your API client code to detect
Deprecation and Sunset headers. Log warnings when these headers are present.Explicitly specify the version
Explicitly specify the version
Rather than relying on the default version, always specify the
X-API-Version header explicitly. This prevents unexpected breaking changes when the default version changes.Subscribe to changelog updates
Subscribe to changelog updates
Stay informed about upcoming changes by subscribing to the changelog or API announcements. This gives you advance notice of:
- New version releases
- Deprecation schedules
- Breaking changes
- Migration guides
Test against new versions early
Test against new versions early
When a new version is announced, test your integration against it well before the sunset date of the old version. This gives you time to:
- Identify breaking changes in your implementation
- Update your code and dependencies
- Test thoroughly in staging
- Deploy with confidence before the deadline
Current Version Status
The current active version is v1 with no deprecation scheduled at this time.When new versions are released or deprecation schedules are announced, this guide will be updated with specific dates and migration information.