The Deel API uses versioning to evolve endpoints while maintaining backward compatibility for existing integrations.
2026-01-01
Expected deprecation: Jan 1, 2027
Header-based: X-Version: 2026-01-01
The Deel API supports URL path versioning. All endpoints include a version prefix in the URL:
The /v2/ prefix identifies the major API version. This pattern remains fully supported across all API reference documentation and existing integrations.
The Deel API uses header-based date versioning as the standard for managing API changes. Instead of changing the URL path, you specify a version date using the X-Version request header:
URL path versioning (/v2/) continues to work alongside header versioning. You do not need to change existing integrations. New versioned changes to API endpoints are introduced through header versions, and the /v2/ URL prefix remains in use.
When both the /v2/ URL prefix and the X-Version header are present, the header takes precedence for version resolution.
X-Version header (YYYY-MM-DD format)X-Version header routes your request to a stable version automaticallyX-Beta: true headerAll existing API endpoints are baselined to version 2026-01-01. Existing integrations that do not send the X-Version header will continue to work with no changes.
A new major version is expected approximately once per year. When a new version is released, the previous version enters deprecation with exactly one year of continued support before sunset.
Use the X-Version request header to pin your integration to a specific API version.
Sending an X-Version value that does not match any published version for the endpoint returns a 400 error. The API does not negotiate or suggest alternative versions.
When X-Version is omitted, the API routes your request to a stable version automatically. Existing integrations continue to work with no changes required.
If you are building a new integration, Deel recommends explicitly setting X-Version to protect against future changes.
Every endpoint version moves through a defined lifecycle. The X-State response header communicates the current state of the version you called.
Beta endpoints provide early access to upcoming API changes. They require the X-Beta: true header and may introduce breaking changes before promotion to Stable.
X-State: beta in the response headersX-Beta headerStable is the default production-ready state. Endpoints in this state are backward-compatible within the same version date.
X-State: stable in the response headersDeprecated endpoints remain functional but have a scheduled removal date. The API signals deprecation through response headers.
Deprecation response header is set to trueSunset response header provides the exact removal date in UTC formatX-State: deprecated in the response headersAfter the sunset date passes, the endpoint is permanently removed. Requests to a sunset version return a 410 Gone response with details to help you migrate.
latest_stable_version to guide migrationsunset_date for referenceThe API includes versioning-related headers in every response to communicate the current state of the endpoint you called.
Monitor the X-State and Deprecation headers in your integration. When you see deprecated, begin planning your migration to avoid disruption at sunset.
Beta endpoints provide early access to upcoming API changes before they are promoted to Stable. Access requires the X-Beta header.
Beta endpoints are experimental and may change without notice. Do not rely on them for production workloads.
The X-Beta header and X-Version header follow strict mutual exclusivity rules:
The X-Beta header accepts only true or false (case-insensitive). Any other value returns a 400 error.
Deel follows a predictable versioning cadence to give you time to plan and execute migrations.
2026-01-01, stable until at least Jan 1, 20272026-06-15). The previous version remains available throughout its lifecycle./v2/ URL prefix remains fully supported. Existing integrations do not need to change their URL structure.Watch for Deprecation: true and the Sunset date header in your API responses. These signal that your current version is scheduled for removal.
Check the changelog for details on what changed in the new version, including any breaking changes to request or response schemas.
Set X-Version to the new date in your sandbox environment and run your integration test suite.
The API returns specific error messages for versioning-related issues.
When you request a sunset version, the API returns a 410 Gone response with migration guidance:
Use latest_stable_version from the response to update your X-Version header.
Common causes:
X-Version value is not in YYYY-MM-DD formatSolutions:
X-Version: 2026-01-01Common causes:
X-Beta: true header is missing when requesting a beta versionX-Beta: true header is present but the version is not in betaSolutions:
X-Beta: true when accessing a beta versionX-Beta when accessing a stable or deprecated versionCause:
Solution:
latest_stable_version from the response bodyX-Version header to the suggested versionSolution:
X-State response header on any API callX-Version header, you are using a stable versionX-Request-ID response header when contacting support for version-related issues