API versioning
Understanding Gusto date-based versioning
Gusto uses date-based API versioning to provide stability while continuously improving our services. This guide explains how versioning works and how to implement it in your integration. For performance and security reasons, we strongly recommend upgrading to the latest API version every quarter.
For all API updates, including new version releases, visit our API changelog .
Important
Version v2024-03-01 is currently in deprecation. View version upgrade guide.
Quickstart
Set your API version using the X-Gusto-API-Version
header:
curl --request GET \
--url https://api.gusto-demo.com/v1/me \
--header 'Accept: application/json' \
--header 'Authorization: Bearer {ACCESS_TOKEN}' \
--header 'X-Gusto-API-Version: 2024-04-01'
- If no header is specified, your API request will default to the minimum API version listed in the Developer Portal. Find this by navigating to your applicationβs details and locating the Default API version field.
- All Gusto API request URLs include
/v1
. This should remain the same for all requests regardless of API version; the value passed into theX-Gusto-API-Version
header determines the date-based API version associated with your API call. - We pass back the
X-Gusto-API-Version
in the response header as a way for callers to confirm that their requestedX-Gusto-API-Version
was respected.
How our API versioning works
We release new versions monthly when backward-incompatible changes are needed, with minor fixes potentially batched into future releases.
If there are no changes requiring immediate release, we wonβt release a new version.
Version lifecycle
Each API version follows a structured lifecycle:
- Upon release of a new API version, the oldest supported version is marked as deprecated. Partners are notified with clear timelines and instructions for upgrading.
- The deprecation period consists of a 12-month phase with two distinct support phases.
- At the end of 12 months, the deprecated version is retired and becomes unusable.
Deprecation timeline
Upon deprecation, every API version receives 12 months of phased support:
Phase | Duration | Support level |
---|---|---|
Full support | 6 months | Bug fixes, security patches, and new features where applicable |
Limited support | 6 months | Critical security fixes only |
End of life | After 12 months | No longer functional |
Deprecation headers
Deprecation headers are HTTP headers included in the API response once a version is marked for deprecation. These headers notify the client of an upcoming resource removal and provide information on when the resource will be removed and where to find instructions on upgrading.
Here is what you can expect:
Deprecation
header: An HTTP datetime value indicating when the resources has been marked as deprecatedLink
header: A link to more information about the deprecated resource and upgrade instructions.Sunset
header: Specifies the date when the resource will be removed. After this date, all calls to the resource will return a406 Not Acceptable
error.
We recommend you to monitor these changes by logging the presence of the aforementioned headers and plan ahead to avoid breaking integrations. This practice also ensures your compatibility with future API versions and helps you stay informed about new features and enhancements.
FAQ
What changes are considered backward incompatible and compatible?
We consider the following to be backward incompatible changes:
- Deleting a resource or API endpoint.
- Deleting a response field.
- Modifying a resource or method URI.
- Modifying an existing field name.
- Modifying required query parameters.
- Modifying authorization.
We consider the following to be backward-compatibleβnon-breaking changes that are additive, and which will be documented and applied to previously-released API version.
- Adding new API endpoints.
- Adding new optional parameters to existing endpoints.
- Adding new response fields.
- Changing the order of properties in existing API responses.
Updated 5 days ago