API GuideAPI ReferenceChangelogFieldwire App
API Guide

Deprecation & Sunset

This page explains how Fieldwire signals that an API version you're using is going away, and what to expect at each stage of that process

Why versions eventually go away

Maintaining every historical version snapshot forever isn't sustainable. Some carry deprecated dependencies or simply block us from evolving the platform. When we need to retire an old version, we do it through a predictable, multi-stage process designed to give you plenty of advance notice and a transparent fallback, never a surprise breaking change.

A version moves through three additional stages beyond normal, active support:

StageWhat it means for you
DeprecatedStill fully functional, but responses now carry headers warning you that this version has a planned end-of-life date. Time to start planning your migration.
SunsetThe version is no longer served. Requests pinned to it are transparently upgraded to the next available version. You keep getting responses, just under different behavior, so nothing breaks abruptly.
RemovedThe old version's code no longer exists at all. By this point, real traffic should already be at zero because of the sunset fallback.

The headers you'll see while a version is deprecated

Once your pinned Fieldwire-Version enters the deprecated stage, every response includes:

Deprecation: true
Sunset:      Wed, 01 Jul 2026 00:00:00 GMT
Link:        <https://developers.fieldwire.com/changelog/deprecation-2026-08-18>; rel="deprecation"
HeaderMeaning
DeprecationSet to true whenever the version you're pinned to has an end-of-life scheduled.
SunsetAn HTTP-date (RFC 7231 IMF-fixdate format) telling you exactly when this version will stop being served. Omitted if a sunset date hasn't been committed to yet, so you'll still get Deprecation: true as an early warning.
LinkPoints you to migration guidance for this deprecation, with rel="deprecation". Follow this link to see what's changing and how to update your integration before the sunset date.

We recommend monitoring for the presence of the Deprecation header in an automated way (e.g. a CI check or alert on your side) rather than relying on manually reading changelogs. That way you find out the moment your integration starts running on borrowed time, straight from the API responses you're already receiving.

What happens at sunset

Once the Sunset date passes, the deprecated version is no longer served. Your requests are not rejected or broken. Instead they automatically fall through to the next available version's behavior, so your integration keeps receiving responses. However, that next version may include the breaking change(s) the deprecation was warning you about, so anything not yet migrated could start behaving differently (different fields, different validation, etc.) from that point on.

In short: sunset does not mean "your calls start failing." It means "you stop getting the old contract and silently start getting the new one." Migrating before the sunset date, on your own schedule, is always the safer path.

Standards we follow

We intentionally build on established web standards rather than inventing our own conventions, so that standard HTTP tooling (proxies, API clients, monitoring) understands these signals out of the box:

As these drafts evolve toward finalized RFCs, we aim to track the standard rather than diverge from it, so tooling built against the spec keeps working against Fieldwire's API.

What to do when you see a Deprecation header

  1. Note the Sunset date (if present), that's your deadline.
  2. Follow the Link header to the migration guide for specifics on what changed.
  3. Update your integration to send a newer Fieldwire-Version (or omit the header to always get
    the latest behavior, if you're able to keep up with changes proactively).
  4. Re-test against the new version before your current one sunsets.

Updated 3 days ago

Did this page help you?