AutoQuote3D API lifecycle and deprecation policy

Public REST operations include a version segment such as /api/v0 in the URL. The v0 surface is a preview contract: AutoQuote3D documents its request and response shapes in OpenAPI, but may make breaking changes before a stable v1 is introduced. Integrations should generate against the current OpenAPI document, pin generated client artifacts, and review contract changes before updating them.

Additive fields and new operations can be introduced within a version. AutoQuote3D uses a new URL version when an established stable contract requires an incompatible replacement. The OpenAPI info.version identifies the published document revision; it does not replace the version segment in request URLs.

An active operation is not deprecated merely because it uses v0. When AutoQuote3D formally deprecates an operation, its OpenAPI operation is marked deprecated: true and responses may include a Deprecation header using the HTTP-date form defined by RFC 9745. A Link response header with rel="deprecation" points to migration guidance.

If an operation has a planned removal date, responses include the Sunset header defined by RFC 8594. Clients should parse that HTTP date, stop creating new dependencies on the operation, and migrate before the stated sunset. Retry logic must not treat deprecation or sunset as transient errors.

Fetch the canonical OpenAPI document from https://www.api.autoquote3d.com/openapi.json during integration updates. Check operationId, deprecated, request and response schemas, security requirements, and documented error responses. At runtime, preserve Deprecation, Sunset, Link, Retry-After, RateLimit, and RateLimit-Policy response headers in logs or telemetry.

MCP protocol versions and MCP tool evolution are separate from REST URL versions. MCP clients should negotiate the protocol through the initialize exchange and inspect the server's current tool and resource lists rather than deriving MCP behavior from REST paths.