For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
SupportDeel Home
OverviewPlatformEmployer of RecordContractorsGlobal PayrollHREmbeddedDeel ITAPI ReferenceChangelog
OverviewPlatformEmployer of RecordContractorsGlobal PayrollHREmbeddedDeel ITAPI ReferenceChangelog
  • Resources
    • Blog
    • Community
    • API spec
  • Get Started
    • Quickstart
    • Sandbox
  • Essentials
    • Authentication
    • API versioning
    • OAuth 2.0
    • Rate Limits
    • Idempotency
    • Best Practices
  • Webhooks
    • Introduction
    • Quickstart
    • No Code
    • Events
    • Simulations
  • Partners
    • Introduction
    • Getting Started
    • Publishing to App Store
LogoLogo
SupportDeel Home
On this page
  • Overview
  • Specifying a version
  • Lifecycle states
  • Response headers
  • Beta access
  • Backward compatibility and migration
  • Error handling
  • Troubleshooting
  • Next steps
Essentials

API versioning

Was this page helpful?
Previous

OAuth2

Next
Built with

Overview

The Deel API uses versioning to evolve endpoints while maintaining backward compatibility for existing integrations.

Current stable version

2026-01-01
Expected deprecation: Jan 1, 2027

Versioning method

Header-based: X-Version: 2026-01-01

URL versioning (legacy)

The Deel API supports URL path versioning. All endpoints include a version prefix in the URL:

https://api.letsdeel.com/rest/v2/people

The /v2/ prefix identifies the major API version. This pattern remains fully supported across all API reference documentation and existing integrations.

Header versioning

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:

X-Version: 2026-01-01

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.

Key concepts

  • Deel uses date-based versioning via the X-Version header (YYYY-MM-DD format)
  • Every endpoint version follows a lifecycle with three states: Beta, Stable, and Deprecated
  • Omitting the X-Version header routes your request to a stable version automatically
  • Beta endpoints require an explicit X-Beta: true header
  • Response headers communicate the lifecycle state of the version you called

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

Version lifecycle timing

PhaseDurationDescription
StableMinimum 1 yearThe version is production-ready and will not receive breaking changes
DeprecatedFixed 1 yearThe version remains functional but a newer version is available. Migration is required before the sunset date.
Sunset—The version is removed. Requests return 410 Gone.

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.

Specifying a version

Use the X-Version request header to pin your integration to a specific API version.

HeaderFormatRequiredDescription
X-VersionYYYY-MM-DDNoPins the request to a specific API version
1import requests
2import os
3
4headers = {
5 "Authorization": f"Bearer {os.getenv('DEEL_API_TOKEN')}",
6 "X-Version": "2026-01-01"
7}
8
9response = requests.get(
10 "https://api.letsdeel.com/rest/v2/contracts",
11 headers=headers
12)

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.

Default behavior (no header)

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.

Lifecycle states

Every endpoint version moves through a defined lifecycle. The X-State response header communicates the current state of the version you called.

StateX-StateAction required
BetabetaOpt in with X-Beta: true; do not use in production
StablestableSafe for production use
DeprecateddeprecatedPlan migration; check Sunset header for removal date
SunsetN/A (410)Migrate to a newer version
Beta

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.

  • Beta endpoints are not recommended for production workloads
  • The API returns X-State: beta in the response headers
  • Once promoted, the endpoint transitions to Stable and no longer requires the X-Beta header
Stable

Stable is the default production-ready state. Endpoints in this state are backward-compatible within the same version date.

  • No special headers are required
  • The API returns X-State: stable in the response headers
  • Breaking changes are only introduced through a new version date
Deprecated

Deprecated endpoints remain functional but have a scheduled removal date. The API signals deprecation through response headers.

  • The Deprecation response header is set to true
  • The Sunset response header provides the exact removal date in UTC format
  • The API returns X-State: deprecated in the response headers
  • You should begin migrating to the newer version before the sunset date
Sunset

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

  • The response body includes latest_stable_version to guide migration
  • The response body includes the sunset_date for reference
  • No further requests to this version will succeed

Response headers

The API includes versioning-related headers in every response to communicate the current state of the endpoint you called.

HeaderValueWhen present
X-Statebeta, stable, or deprecatedEvery successful response
DeprecationtrueWhen the version has a scheduled sunset date
SunsetUTC date string (e.g., Thu, 01 Jan 2028 00:00:00 GMT)When deprecation is active
X-Request-IDUUIDEvery response

Monitor the X-State and Deprecation headers in your integration. When you see deprecated, begin planning your migration to avoid disruption at sunset.

1import requests
2import os
3
4headers = {
5 "Authorization": f"Bearer {os.getenv('DEEL_API_TOKEN')}",
6 "X-Version": "2026-01-01"
7}
8
9response = requests.get(
10 "https://api.letsdeel.com/rest/v2/contracts",
11 headers=headers
12)
13
14state = response.headers.get("X-State")
15is_deprecated = response.headers.get("Deprecation") == "true"
16sunset_date = response.headers.get("Sunset")
17
18if is_deprecated:
19 print(f"Warning: This API version is deprecated. Sunset date: {sunset_date}")

Beta access

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.

$curl -X GET 'https://api.letsdeel.com/rest/v2/contracts' \
> -H 'Authorization: Bearer YOUR-TOKEN-HERE' \
> -H 'X-Beta: true'

The X-Beta header and X-Version header follow strict mutual exclusivity rules:

X-BetaX-VersionResult
OmittedOmittedStable version (default)
OmittedStable dateThat specific stable version
trueOmittedBeta version (if available)
trueBeta dateThat specific beta version
OmittedBeta date400 error — beta access required
trueStable date400 error — version is not in beta

The X-Beta header accepts only true or false (case-insensitive). Any other value returns a 400 error.

Backward compatibility and migration

Deel follows a predictable versioning cadence to give you time to plan and execute migrations.

  • Baseline version: All existing endpoints are set to 2026-01-01, stable until at least Jan 1, 2027
  • New versions: Breaking changes are introduced as new date versions (e.g., 2026-06-15). The previous version remains available throughout its lifecycle.
  • Major versions: A new major version is expected approximately once per year, rolling up the latest changes
  • Stability guarantee: Each version remains stable for a minimum of one year from release
  • Deprecation period: Superseded versions receive exactly one year of continued support before sunset
  • URL path versioning: The /v2/ URL prefix remains fully supported. Existing integrations do not need to change their URL structure.

Migration checklist

1

Monitor response headers

Watch for Deprecation: true and the Sunset date header in your API responses. These signal that your current version is scheduled for removal.

2

Review the changelog

Check the changelog for details on what changed in the new version, including any breaking changes to request or response schemas.

3

Update X-Version in sandbox

Set X-Version to the new date in your sandbox environment and run your integration test suite.

4

Test thoroughly

Pay attention to changed response shapes, removed fields, and updated validation rules. Verify that your error handling covers the new version.

5

Roll out to production

Update X-Version in your production environment. Monitor logs and response headers to confirm the new version is active.

Error handling

The API returns specific error messages for versioning-related issues.

StatusConditionError message
400Malformed X-Version”Invalid X-Version header format. Expected YYYY-MM-DD format (e.g. 2026-01-01)“
400Version not found”The provided X-Version value is invalid for the requested endpoint.”
400Beta version without X-Beta flag”This API version is in beta. Please include the X-Beta: true header to access beta versions.”
400X-Beta flag on non-beta version”This API version is not in beta. Please do not include the X-Beta header to access stable versions.”
400Invalid X-Beta format”Invalid X-Beta header format. Expected ‘true’ or ‘false’.”
410Sunset version requestedSee response body below

Sunset response (410 Gone)

When you request a sunset version, the API returns a 410 Gone response with migration guidance:

Example 410 response
1{
2 "errors": [
3 {
4 "code": "endpoint_sunset",
5 "message": "This API version has been sunset and is no longer available.",
6 "details": {
7 "requested_version": "2026-01-01",
8 "latest_stable_version": "2027-01-01",
9 "sunset_date": "2028-01-01T00:00:00.000Z"
10 }
11 }
12 ]
13}

Use latest_stable_version from the response to update your X-Version header.

1import requests
2import os
3
4headers = {
5 "Authorization": f"Bearer {os.getenv('DEEL_API_TOKEN')}",
6 "X-Version": "2026-01-01"
7}
8
9response = requests.get(
10 "https://api.letsdeel.com/rest/v2/contracts",
11 headers=headers
12)
13
14if response.status_code == 410:
15 error_data = response.json()
16 details = error_data["errors"][0]["details"]
17 print(f"Version {details['requested_version']} has been sunset.")
18 print(f"Migrate to version: {details['latest_stable_version']}")
19elif response.status_code == 400:
20 print(f"Version error: {response.json()}")

Troubleshooting

400 error with X-Version header

Common causes:

  • The X-Version value is not in YYYY-MM-DD format
  • The version date does not exist for this endpoint

Solutions:

  • Verify the header value matches the exact format: X-Version: 2026-01-01
  • Check the changelog for available version dates
  • Remove the header to use the default stable version
400 error accessing a beta endpoint

Common causes:

  • The X-Beta: true header is missing when requesting a beta version
  • The X-Beta: true header is present but the version is not in beta

Solutions:

  • Include X-Beta: true when accessing a beta version
  • Remove X-Beta when accessing a stable or deprecated version
  • Verify whether the endpoint is still in beta or has been promoted to stable
410 Gone response

Cause:

  • The requested version has been sunset and is no longer available

Solution:

  • Read the latest_stable_version from the response body
  • Update your X-Version header to the suggested version
  • Test the new version in sandbox before deploying to production
Not sure which version I am using

Solution:

  • Check the X-State response header on any API call
  • If you are not sending the X-Version header, you are using a stable version
  • Use the X-Request-ID response header when contacting support for version-related issues

Next steps

Authentication

Learn how to authenticate API requests

Rate limits

Understand API rate limits and best practices

Changelog

Review changes across API versions

Sandbox

Test version pinning in the sandbox environment