Skip to content

Developer resources Deprecation policy

Proquiro API Deprecation Policy

This page is the canonical statement of how the Proquiro Public API is versioned and how deprecations are signalled. Agents and integrators can rely on it: nothing documented in the OpenAPI specchanges behavior without a versioned replacement and the notice period below.

Versioning scheme

  • The API is versioned in the URL path. The current version isv1: /api/v1/demo-request and /api/v1/health.
  • The unversioned /api/* paths are permanently supported aliases of v1 and will never change behavior.
  • Within a version, changes are additive only: request shape, response shape, and error codes are never removed or repurposed.
  • Breaking changes only ship in a new path version(/api/v2/*), alongside the old one.

How deprecation is signalled

A deprecated endpoint keeps working for at least 6 months after the deprecation is announced. During that window it is signalled machine-readably on every response:

  • A Deprecation response header (per the IETF deprecation-header standard) from the moment the deprecation is announced.
  • A Sunset response header (RFC 8594) carrying the retirement date once one is scheduled — never less than 6 months out.
  • deprecated: true on the affected operations in theOpenAPI spec, with the replacement operation named in the description.
  • An entry on the product updates changelog announcing the deprecation and its replacement.

After the sunset date, retired endpoints return 410 Gone with the standardstructured JSON error pointing at the replacement — never a silent behavior change.

Currently deprecated endpoints

None. No Proquiro Public API endpoint is deprecated or scheduled for sunset. When that changes, this page and the signals above are updated first.

Questions

See the versioning summary on the developer hub, or contact the team for partner integration timelines.