Changelog

Changes to the public API, newest first. Within v1, changes only add things. No entry is breaking. Put a new entry at the top, in the same commit as the change.

1.3.2 · 2026-10-23

Breaking: none

Added

• The new error DURATION_OPTION_REQUIRED (400) from POST /create-order. A product with duration options needs duration_option in its line. The error has the field product. Before, such a line got the price of the product itself. For a product with a price only in its duration options, that price was 0.

1.3.1 · 2026-10-20

Breaking: none

Added

• The new order status request. A shop can let its customers send a request instead of a paid order. A request has no payment. The shop answers it with a quote. Orders that you create with POST /create-order do not change: they never get this status.

1.3.0 · 2026-10-19

Breaking: none

Added

• Variants. A shop can give a product variants, for example sizes. Each variant has its own stock. A product has the new fields variant_label and variants (each with id, name, surcharge, and image). A product without variants has an empty list.
• The new optional parameter variantId in GET /check-availability, GET /check-availability-for-period, and each line of POST /calculate-total. The new optional field variant in each line of POST /create-order. It is required for a product with variants.
• The new field variant in each order line of an order. It has the id and the name of the variant at the moment of the order.
• The new field variantId in each line of the calculate-total response.
• The new error INVALID_VARIANT (400). The variant does not belong to the product, or the product has no variants.

Changed

• The error VARIANT_REQUIRED (400) now also comes from the availability requests and from calculate-total. The order request no longer refuses a product with variants when the line has a variant.
• The availability requests for a product with variants now need variantId. A shop front that sells no variants works as before.

1.2.0 · 2026-10-18

Breaking: none

Added

• API tokens. The Owner of a shop makes tokens in the admin app. A token gives read access to the orders of that shop only.
• The new endpoints GET /orders and GET /orders/{orderId}. They need a token with the scope orders:read. They give the orders of your shop with the personal data of the customer. Send the token in the header Authorization: Bearer <token>.
• The new error codes UNAUTHORIZED (401) and INSUFFICIENT_SCOPE (403).
• A token has its own rate limit: 600 requests each minute. A request with a token that is not valid counts against the IP address.

Changed

• The Authorization header was reserved. The shop front endpoints still ignore it. Only the endpoints with the tag Orders use it.

1.1.3 · 2026-10-18

Breaking: none

Added

• The new error VARIANT_REQUIRED (400) from the order request. A shop can give a product variants, for example sizes. Ordering a product with variants is not possible through the API yet; the error has the field product.

1.1.2 · 2026-10-17

Breaking: none

Added

• The order has the new field payment_method. It is custom when the customer pays the shop. It is null while we did not confirm an online payment. After the confirmation, it is the id of the payment method, for example ideal.

Changed

• We built a reference shop only from the guide (the example shop). We completed the documentation with what we found.
• The guide and the reference now describe these points:
  • The last day of a day period is included.
  • How to book hours with the slots: dateStart is the slot_start of the first slot. dateEnd is the slot_end of the last slot.
  • How to encode a query string.
  • The form of details of VALIDATION_FAILED.
  • When to make a new Idempotency-Key.
  • Which responses to retry.
  • How to recognize an order that the customer pays at the shop (payment_method).
• The behavior of the API is the same.

1.1.1 · 2026-10-17

Breaking: none

Changed

• We rewrote the guide, the introduction, and all descriptions in the reference in Simplified Technical English (ASD-STE100). The behavior of the API is the same.
• We changed the wording of the message text of the errors. The code of each error is the same. Match on code, not on message.

Fixed

• Hourly start-time slots from GET /check-availability-for-period now give available as an integer, as the reference describes. Before, it was a string. The undocumented field rented is removed from the slots.

1.1.0 · 2026-10-16

Breaking: none

Added

• timezone on GET /partners/{slug}: the IANA timezone of the shop (for example Europe/Amsterdam).
• Idempotency-Key header on POST /create-order. A retry with the same key and body gives the original response. No second order is created. We keep keys for 24 hours. New error codes: IDEMPOTENCY_KEY_REUSED (422) and IDEMPOTENCY_IN_PROGRESS (409).
• limit and cursor on the category and product lists, and meta.next_cursor in their responses. Requests without them work as before.
• X-Request-Id header on each response, error.request_id in each error body, and an optional X-Request-Id request header that we return.
• Troubleshooting ("Failed to fetch"), versioning policy, and deprecation policy in the introduction.

Fixed

• The documentation now says that hourly date-times are real instants with an offset or Z (for example 2026-10-20T09:00:00+02:00, the same instant as 2026-10-20T07:00:00Z). The earlier text said "wall-clock time of the shop with the label Z". That text was wrong. The API never read the values in this way.

1.0.0 · 2026-10-16

Breaking: none

Added

• Shops, categories, products, legal pages, countries, opening hours, and payment methods.
• Availability: check one product, check a period (calendar and time slots), and list the products that are available in a window.
• Checkout: calculate a total, create an order with its checkout_url, and read an order.
• Errors in one form ({ "error": { "code", "message" } }), rate limits for each IP address, and CORS for each shop domain.