AnyToURL
Start Uploading
← Docs

API Versioning & Deprecation Policy

How AnyToURL versions its public API, how deprecations are signalled, and what agents can rely on.

Versioning

The AnyToURL API is versioned with the API-Version header. Version 1 is the current stable surface. Every API response echoes the served version in the API-Version response header, so clients can verify they are talking to the surface they expect.

GET /api/config/public
API-Version: 1

Omitting the header is equivalent to requesting version 1. The published OpenAPI specification always describes the current stable surface.

What changes between versions

  • Breaking changes — changes that remove or rename a field, change a response shape, or alter authentication requirements — ship as version 2 under the same paths. Version 1 keeps serving the previous contract.
  • Additive changes — new endpoints, new optional fields, new response properties — are backwards compatible and may appear inside a stable version without a version bump.

Deprecation signals

Before a deprecated operation is removed, clients receive machine-readable signals:

  1. Deprecation / Sunset response header on the affected operation. The Sunset header carries the date the operation is expected to stop being served.
  2. x-deprecation-policy in the OpenAPI specification describes the policy in machine-readable form.

Deprecated operations remain supported for at least 180 days after the replacement ships. During that window the old operation keeps working unchanged.

Agent guidance

  • Send API-Version: 1 explicitly so your integration is pinned.
  • Read the Sunset header on every response; if it appears, migrate to the replacement operation.
  • Before adopting an endpoint, check /openapi.json for the current schema.
  • Breaking changes never land without a version bump and a documented replacement.

Questions

Contact support@anytourl.com with any questions about the API contract.