Deprecation policy

We never remove or rename a field, resolver, or enum value in the partner-facing GraphQL API without warning. This page is the contract you can build against.

The guarantee

Deprecated fields and resolvers stay available for at least 90 days from the day the deprecation is announced. The exact removal date — the sunset date — is published in the deprecation itself, so you never have to guess.

A deprecation is never a silent rename: the replacement ships first, the old field keeps working alongside it, and only after the sunset date passes does the old field go away.

How you’ll find out

Deprecations surface in four places:

The schema itself. Every deprecated field carries the standard GraphQL @deprecated directive, so introspection-aware tooling (GraphiQL, codegen, linters such as graphql-eslint) flags usages automatically. The reason string always starts with the sunset date:
```
akinPrimary: String @deprecated(reason: "Sunset 2026-09-08: Use primary instead")
```
The GraphQL reference. Deprecated operations get a warning banner and deprecated fields are marked in the type tables, with the sunset date and the replacement.
The changelog. Every new deprecation is announced as a changelog entry, which also lands in the RSS feed.
Your codegen. If you generate types from our schema, the @deprecated directive flows into your generated code (e.g. @deprecated JSDoc in TypeScript), so your own compiler warns you.

Reading a sunset date

The machine-readable convention: every deprecation reason starts with Sunset YYYY-MM-DD: followed by the human explanation — usually what to use instead. The date is the first day the field may be removed; it is always at least 90 days after the deprecation first ships.

What we enforce on ourselves

CI fails our own builds when the policy is violated:

A field cannot be removed unless it was deprecated first and its sunset date has passed.
A deprecation without a parseable sunset date cannot merge.
Once a sunset date passes, our build fails until the field is either removed or renewed with a later date — stale “removed soon” warnings that linger for years can’t happen here.

What you should do

Treat the @deprecated banner as a migration ticket with a due date, not background noise.
Subscribe to the changelog RSS feed so deprecations reach you when they ship, not when they break you.
If a 90-day window is genuinely too tight for your integration, contact your AKIN Travel onboarding contact before the sunset date — renewing a sunset is cheap before removal, impossible after.