API versioning and changelog

Q: How is the API versioned?

The URL carries the major version: . Everything documented here is . Every response carries the dated version that served it in the header - currently . Webhook payloads carry the same value as , and the OpenAPI document's matches it. Log the header alongside your integration's errors; it tells you exactly which behaviour you were talking to.

Q: What can change without a new version?

only changes in backwards-compatible ways. We may, without notice: add new endpoints; add new optional request fields or query parameters; add new fields to responses and webhook payloads; add new event types to the webhook catalog; add new values to enums such as , or ; add new error s; change the wording of and in errors. Write your integration so these don't break it: ignore unknown fields and event types, treat an unknown enum value gracefully, and branch on error rather than on message text. We will not , within : remove or rename a field, endpoint or event type; change a field's type or meaning; make an optional request field required; or change an error or its anchor on the errors page. A change like that would ship as a new dated version with a changelog entry and advance notice.

Read time: 3 minutes. Who it's for: Developers who want to know what can change under their integration, and when.

How is the API versioned?

The URL carries the major version: https://api.quotway.com/v1/…. Everything documented here is v1.
Every response carries the dated version that served it in the QuotWay-Version header - currently 2026-10-01. Webhook payloads carry the same value as api_version, and the OpenAPI document's info.version matches it.

Log the QuotWay-Version header alongside your integration's errors; it tells you exactly which behaviour you were talking to.

What can change without a new version?

v1 only changes in backwards-compatible ways. We may, without notice:

add new endpoints;
add new optional request fields or query parameters;
add new fields to responses and webhook payloads;
add new event types to the webhook catalog;
add new values to enums such as status, source or actor;
add new error codes;
change the wording of title and detail in errors.

Write your integration so these don't break it: ignore unknown fields and event types, treat an unknown enum value gracefully, and branch on error code rather than on message text.

We will not, within v1: remove or rename a field, endpoint or event type; change a field's type or meaning; make an optional request field required; or change an error code or its anchor on the errors page. A change like that would ship as a new dated version with a changelog entry and advance notice.

API changelog

2026-09-30 - order-discount checks

Compatible behaviour change; no new fields or error codes.

POST /v1/quotes/{id}/send-proposal judges each line at its effective price (its share of the whole-quote discount taken off) for the price floor (409 below_price_floor) and for approval policies. A proposal whose only discount is on the order can now return below_price_floor or outcome: "awaiting_approval" where it didn't before.
A staged proposal with a fixed-amount discount larger than its subtotal is refused with 422 invalid_proposal instead of the discount being capped at the subtotal. confirm_below_floor doesn't override it.

2026-10-01 - v1 launch

The first public version of the QuotWay API and webhooks. Enterprise plan.

REST API at https://api.quotway.com/v1: quotes (list, retrieve, create), per-quote events, the events feed, messages, send the staged proposal, documents, analytics summary, and webhook endpoint management. OpenAPI 3.1 at https://api.quotway.com/openapi.json.
API keys with five scopes, test keys for development stores, expiry, IP allowlists, 24-hour roll overlap and a per-key request log (Settings → Integrations → API keys).
Outbound webhooks for 25 quote event types, signed to the Standard Webhooks specification, with retries over about 3.7 days, auto-disable after 5 days of failures, secret rotation with a 24-hour overlap, test pings and a resendable delivery log (Settings → Integrations → Webhooks).
RFC 9457 errors, cursor pagination, Idempotency-Key on every POST, and rate limits of 120 requests per minute per key and 300 per store.

2026-09-30 - follow-ups

Compatible changes; no fields removed or renamed.

New endpoint GET /v1/quotes/{id}/documents lists a quote's Proposal, Confirmation and Pro-forma PDFs; download one with GET /v1/documents/{id}. See Documents.
Creating an API key requires the store Admin to accept the API Terms of Use, and warns when the key is given the read_customer_data scope.
Webhook deliveries are sent round-robin across endpoints and stores. While an endpoint is down, its queued deliveries wait for the next retry without using up their own attempts. See Webhooks - Retries.