API Versioning

Overview

The Extend API uses versioning to ensure that your integration remains stable as we evolve our API. The version is specified using the x-extend-api-version header in your requests.

Backwards-compatible Changes

We consider the following changes to be backwards-compatible:

1. Adding new APIs
2. Adding new optional request parameters to existing APIs
3. Adding new properties to existing API responses

Specifying a Version

To specify an API version, include the x-extend-api-version header in your requests.

The API version is specified in the format YYYY-MM-DD and corresponds to the date of the release that introduced the breaking changes.

1
curl -X POST https://api-prod.extend.app/workflow_runs \
2
-H "Authorization: Bearer YOUR_API_KEY" \
3
-H "x-extend-api-version: 2025-04-21" \
4
-H "Content-Type: application/json" \
5
-d '{ ... }'

Important: If you don’t specify a version:

• When using an API key made before April 21, 2025, you’ll automatically use the legacy version (2024-12-23)
• When using an API key made after April 21, 2025, you will receive an error and be required to specify an API version.
• Some organizations may default to a legacy version for backward compatibility predating the introduction of the x-extend-api-version header. Reach out to the Extend team if you need to change this.

Note: The v1 prefix on the routes is legacy and will be deprecated in the future. We recommend specifying the version using the x-extend-api-version header.

Webhook Endpoints

When you create a webhook endpoint in the Extend dashboard, you will be prompted to select the API version you’d like to use. All webhook notifications sent to that endpoint will include the same API version in the x-extend-api-version header, ensuring consistency in payload formats.

We strongly recommend keeping the versions defined on your webhook endpoint in sync with the version specified in your requests.

API Version Changelog