Flavoso APIPublishingChangelog

Changelog

What changed in the API, with dates. Within v1, only non-breaking additions arrive.

How the API changes

Within v1, only non-breaking additions arrive: new fields, new routes, new error codes, new events. Anything breaking comes only in a new version, and the old one keeps running for at least six months afterwards. Flavoso-Api-Version and api_version name the version date.

8 October 2026: final polish before the first POS systems

Before the first POS systems go live, we tightened the contract in a few places. Some of it is stricter than before; it still comes within v1 because no integration was live yet. If you built against an earlier version, check these points.

  • Version date: Flavoso-Api-Version and api_version of new events now say 2026-10-08. Events delivered or fetched before keep 2026-10-04.
  • Body size: a body larger than the operation accepts (64 KB, 2 MB for PUT /menu, counted in bytes) gets 413 payload_too_large instead of 400 invalid_request.
  • Unknown is an error: an unknown query parameter or body field gets 400 invalid_request with param, on every operation.
  • Timestamps need a time zone: updated_since, created_since, starts_from and the other timestamps of a request, including until of POST /store/pause, must carry Z or an offset, otherwise 400. An unencoded + in a query string is accepted before the offset.
  • Creating answers 201: POST /menu/categories, /menu/products, /menu/option-groups, /menu/option-groups/{id}/options, and POST /store/closures for a new day (200 when it replaces one).
  • Accepting: POST /orders/{id}/accept moves a pending order to the next status the restaurant uses (not always confirmed); an order already past pending comes back unchanged with 200, a completed or cancelled one answers 409 invalid_transition.
  • Order options: items[].options[] carry id, group_id and group_name (null for older orders).
  • Menu: new GET /menu/options; the response of PUT /menu puts warnings before ids; a test restaurant keeps at most 50 images from image_url (beyond that, PUT /menu warns with images_capped and a single product answers 400), and resetting deletes them; menu.synced names the connection_id that synced.
  • Concurrent writes: a write to the menu or the store (/store) that collides with another change three times in a row answers 409 conflict with Retry-After instead of 500. Send it again unchanged afterwards.
  • Events: GET /events with an after that is no longer kept continues with the oldest kept event and says gap: true instead of answering 400; after=latest starts at now; next_after is always set. data.object.updated_at of order and reservation events is the time of the reported change. store.paused and store.resumed carry the store as object; store.updated also reports order_statuses; reservation.updated also reports a changed note.
  • Rejecting instead of truncating: a pause note over 140 characters and an order reason over 200 get 400 with param instead of being truncated.
  • Scopes: GET /tables and GET /areas also work with reservations:read.
  • Fixes: order.paid no longer promises payments recorded on site (Flavoso records none); an expired or revoked token no longer counts toward the limit per IP address and always gets 401; a PATCH /reservations/{id} that answers 409 has changed nothing; an Idempotency-Key whose first request never finished is free again after 2 minutes; external_id follows one rule everywhere (no space at the start or end, no control characters).

6 October 2026: the developer platform

The big expansion: POS and other systems can now maintain the menu, take over orders, manage hours and reservations and reconcile sales.

  • Menu: PUT /menu syncs the whole menu (merge, replace, dry_run); POST /menu/availability reports up to 500 entries at once; categories, products, option groups and options can be created, changed and deleted one by one; image_url; every object carries external_id and updated_at.
  • Orders: POST /orders/{id}/acknowledge takes over an order with your own id; new filters paid, acknowledged, created_since, created_until, external_id; new fields source, external_id, acknowledged_at and tax with tax lines.
  • Store: GET /store names contact, address, location, minimum order, lead times, delivery hours and upcoming special days; new: PATCH /store, GET and PUT /store/hours and the special days under /store/closures.
  • Tables and areas: GET /tables, GET /areas.
  • Reservations: POST /reservations, PATCH /reservations/{id}, GET /reservations/availability; new filters starts_from and starts_until.
  • Reports: GET /reports/sales and GET /reports/products, with the new scope reports:read.
  • Fetching events: GET /events and GET /events/{id}. Events are now created for every active connection, even without a webhook.
  • New event types: order.paid, store.updated, app.scopes_changed, menu.category.*, menu.product.created and .deleted, menu.option_group.*, menu.option.created and .deleted, menu.synced (one event per sync). menu.product.updated and menu.option.updated arrive on every field change, with changed and previous.
  • Test and live: livemode in GET /me and in every event. GET /me also names tenant.country, plan and rate_limit.
  • Errors: param names the faulty field; new codes external_id_taken, slot_unavailable, limit_exceeded.
  • OAuth: a refresh token that was already exchanged is still accepted for 60 seconds.
  • Webhooks: every delivery with every attempt in the console, “Resend”, test events of every type; Flavoso-Delivery-Attempt also counts manual sends.
  • Tools: request log, API explorer, test tokens, app directory, postman.json, an operationId on every operation of the specification, and this documentation.

5 October 2026: the new address

The API has its own address now: https://api.flavoso.com. Tokens and responses stay the same, and the old addresses keep working. You only need to act if your app compares iss with a fixed value.

  • Routes: every route lives under https://api.flavoso.com/v1, including openapi.json and postman.json.
  • OAuth: token at https://api.flavoso.com/oauth/token, revocation at https://api.flavoso.com/oauth/revoke, metadata at https://api.flavoso.com/.well-known/oauth-authorization-server. The consent screen stays at https://app.flavoso.com/oauth/authorize, because that is where the owner signs in.
  • Issuer: issuer in the metadata and iss on the redirect are now https://api.flavoso.com instead of https://app.flavoso.com. If your app compares iss with a fixed value, update it; better still, read it from the metadata.
  • Old addresses: https://app.flavoso.com/api/public/v1/… and https://app.flavoso.com/api/oauth/… keep answering; the old metadata address redirects to the new one.

4 October 2026: the first version

The first version of v1, with sign-in via OAuth 2.0 and PKCE: read, accept, reject, cancel and advance orders; read the menu, report sold-out items and prices; pause the store; read reservations and set their status; signed webhooks.

Still unclear? Write to support@flavoso.com and include the id from X-Request-Id. It lets us find your request in the log.