---
title: "API versioning and changelog"
description: "How the QuotWay API is versioned - v1 in the URL, the 2026-10-01 QuotWay-Version header, what counts as a compatible change - and the API changelog."
url: "https://www.quotway.com/ja/docs/api/versioning"
type: "documentation"
category: "api"
updated: "2026-09-30"
locale: "ja"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# API versioning and changelog

**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 `code`s;
- 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](/docs/api/errors). 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](/docs/api/documents).
- Creating an API key requires the store Admin to accept the [API Terms of Use](/api-terms), 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](/docs/api/webhooks#retries).

## Related

- [API reference](/docs/api/reference)
- [Product changelog](/changelog)