Changelog

Public image payloads no longer expose the server-only absoluteFilePath field, including nested menu images. Consumers must use fullUrl to display or retrieve an image.

Direct image uploads now canonicalize unsafe filename punctuation before storage, while explicit renames reject unsafe names with 400 invalid_parameters. Menu JSON imports canonicalize legacy punctuation before storing an image, and previously stored unsafe names are canonicalized in public responses. In all flows, filenames are trimmed, NFKC-normalized, limited to 255 characters, and exposed using only Unicode letters and numbers, spaces, underscores, dots, and hyphens.

A table order whose restaurant point of sale does not answer now returns restaurant_offline (503) instead of 200. The injection into the table bill is confirmed by the point of sale inside the request, so a silent one meant the call answered success for an order that was never added to any bill and never would be. Only silence maps to this code: a point of sale that answers and declines keeps its previous behaviour. After a 503 on a table order, retry with a new idempotency-key, since reusing the previous one returns the earlier non servable order as a success.

GET /table_layout is now read from the restaurant own box first, with the platform copy as a fallback when the box cannot answer, so the endpoint still responds while the restaurant is offline. The box is asked first because the box is what accepts or refuses an order on a table: a plan edited in the back office but not yet published to the point of sale is no longer reported as orderable. A new source field on the response says which of the two answered, box or cloud. A restaurant whose box is not enrolled is served from the platform copy.

Order metadata now has a platform-reserved key: kioskPaymentState. On KIOSK orders (channelId 1) placed to be paid at the counter (willPayLater true, amount left to pay > 0), POST /orders sets metadata.kioskPaymentState to NOT_PAID_AT_KIOSK; on any other kiosk order a client-provided value for that key is removed. All other metadata keys are preserved, and non-kiosk orders are untouched. The key is returned in the order metadata by the order read endpoints, and stays NOT_PAID_AT_KIOSK even when the counter sale is reported as paid through a synthetic ExternalPayment.

Documented the metadata field of the OmnichannelOrder webhook payload, including the platform-reserved kioskPaymentState key: an orders.paid delivery can carry status PAID and an ExternalPayment payment for a kiosk order the guest was expected to settle at the counter. Clarified that the key is written once at order creation and never updated, and that NOT_PAID_AT_KIOSK is the only value the API writes.

Clarified the metadata field of POST /orders: it must parse as valid JSON, otherwise the order is rejected with 400 order_metadata_invalid, and it should be a JSON object. On a kiosk pay-at-counter order whose metadata is valid JSON of another shape (array or scalar), the API replaces the whole value with the reserved kioskPaymentState key instead of merging into it.

Added the metadata field to the POST /orders and GET /v1/orders response examples, which already documented it in the shared order property table, and restored the missing message property in the GET /v1/orders and GET /v1/orders/{orderId} response envelopes. Also clarified the payment status at creation for a kiosk pay-at-counter order: it remains null when settlement is deferred to a receiving POS; without such a POS, POST /orders immediately returns the numeric value 1 (PAYMENT_OK) through the synthetic ExternalPayment, while order reads and webhooks report status PAID.

Documented which order reads expose the metadata field, and therefore the reserved kioskPaymentState key: GET /v1/orders, GET /v1/orders/{orderId}, GET /v1/orders/uuid/{orderUuid} and the order webhooks all return it, while the lightweight GET /v1/orders/search payload never loads it and always returns metadata null. Added metadata to the GET /v1/orders/search and GET /v1/orders/uuid/{orderUuid} response examples.

Documented which creation paths enforce the reserved kioskPaymentState metadata key: POST /orders/bulk shares the order-creation code of POST /orders, so a KIOSK-channel bulk order also has a client-provided value for that key removed, and the key is never set there because bulk payloads carry no willPayLater field. Multi-restaurant orders keep their metadata untouched.

Completed the eReporting error and parameter contract: permission_denied is a 401 when the account's role may not read eReporting (only Brand, Brand Group and Restaurant accounts may) and a 403 when the restaurantId is outside its perimeter; an unknown restaurantId answers 400 restaurant_not_found, while a restaurant that exists but has been closed or deactivated answers 403 permission_denied, a documented limitation to plan exports around. Documented that any query key other than those listed is refused with 400 invalid_parameters (brandId is resolved by the API and must not be sent), that a closureId is at most 128 characters and must be percent-encoded when it contains a slash, and that the reporting platform is given 120 seconds to answer an export before a 502 io_data_platform_unreachable.

Documented the eReporting response payloads field by field: the daily report's orders[] are fiscal category aggregates (GOODS_VAT, SERVICES_VAT) and not individual orders, its restaurantId is returned as a string, and its payments[] carry one entry per payment method AND VAT rate; a closure's payments[] are not split per rate and carry a tip but no currency; nextCursor is null on the last page of a closure's orders, whose orderId is the reporting platform's own and not the Innovorder orderId. Clarified that GET /v1/ereporting/closures/{closureId}/orders is authorized by the reporting platform rather than against the local perimeter, so a closure you may not read answers io_data_platform_request_rejected with a 403 or 404 instead of permission_denied, and that the deactivated-restaurant limitation does not apply to it. Stated the 150-second ceiling the API keeps a request open, on all four routes.

Separated, on the eReporting routes, what this API validates from what the reporting platform validates, because the two answer different error codes. Dates are checked on their shape only (four digits, two, two) and not as calendar dates, so a value such as 2026-02-31 clears this API and is refused upstream as io_data_platform_request_rejected rather than invalid_parameters; likewise the export range is not bounded here, so neither its 92-day cap nor startDate preceding endDate is enforced locally, and a refused range carries the platform's own 400 under that same code. Documented that a closureId made only of dots is refused with a 400, and that the API never retries the reporting platform on the caller's behalf: a 502 is one failed attempt, not an exhausted retry budget.

POST /orders now refuses a Sit-in table order whose tableId is not part of the table layout of the restaurant's master POS device: table_not_found (404), with restaurantId and tableId in extraData, and no order is created. Documented the three conditions that trigger the injection of an order into a table's shared bill (MODE_SIT_IN + tableId + willPayLater) and added the tableId request field to the create payload reference.

POST /orders no longer rewrites failures raised while persisting the order into create_order_max_retries_reached (409, "please try again"). Each failure is now returned with its own status and code, so a deterministic refusal can be told apart from a transient fault; retry only on 5xx and network timeouts, reusing the same idempotency-key. A point-of-sale notification failure still never costs the order.

POST /orders/preview accepts willPayLater: true with payments omitted, exactly as with an empty array; previously only the empty array was accepted and an omitted payments returned invalid_order_payload (400). Sending willPayLater: true with a non-empty payments array is still refused.

Creating, updating or deleting a room now moves updatedAt on the table layout that contains it, and updating a room also moves the room's own updatedAt, even when only its tables changed. Integrations that poll a layout and diff updatedAt no longer miss table changes.

Redesigned the developer documentation with a responsive pixel-art visual system, contextual architecture diagrams, a faster mobile-friendly homepage, and improved social sharing previews.

Documentation pages now have dedicated canonical URLs, faster lazy loading, mobile-friendly navigation, and improved cross-page links. Search now covers the complete documentation index.

New Sales & Catalog Synchronization integration guide: service-account authentication, incremental order extraction through ticketStartDate/ticketEndDate on lastUpdateDate, idempotent pagination and correction handling, neutral data mappings, and menu hash-map catalog refresh.

Clarified that ticketStartDate and ticketEndDate filter lastUpdateDate on GET /v1/orders, and corrected the menu hash-map description to list its actual top-level catalog structures.

New eReporting integration guide: aggregated B2C sales data for the French e-reporting obligation (RFE), per restaurant and business date: daily report, closures, orders of a closure, and file export (JSON, or a ZIP of two CSVs) over a period. These endpoints answer the payload directly, without the { status, code, message, data } envelope, and require an Authorization Bearer access token (X-API-Key is not accepted on them).

Corrected the POST /oauth/login documentation: removed the erroneous expires_in field from response examples (this field is not returned by the API) and documented the real access token validity - 24 hours, or 14 days when rememberMe is true. When the token expires the API responds with a 401 error (token_expired).

Corrected the POST /oauth/login documentation: removed the erroneous expires_in field from response examples (this field is not returned by the API) and documented the real access token validity: 24 hours, or 14 days when rememberMe is true. When the token expires the API responds with a 401 error (token_expired).

New Stripe Payments integration guide: platform (Stripe Connect) model, payment metadata contract for POST /orders (stripePaymentMethodId / cardId as a JSON-encoded string), saved cards via the POST /cards/v2 SetupIntent flow, and 3-D Secure handling (required_action response, POST /orders/confirm). Stripe Checkout is not supported; the platform publishable key is provided through an integration project (support@innovorder.fr).

Corrected the POST /cards/v2 documentation: cardToken is a Stripe PaymentMethod id (pm_…) obtained by confirming the SetupIntent returned when calling without cardToken; the success response contains cardId, name, brand and last4.

Documented three new customer account webhook events: customer.account.added, customer.account.updated (fired on profile, badge, e-wallet balance, or activation-status changes), and customer.account.deleted (account archived). Added/updated deliveries carry a full account snapshot (email, balance, payment type, badges, activation status).

New Customers page documenting the first-login mandatory password change flow: detecting the expired default password after login (customer.passwordExpiresAt), the 401 password_expired behavior, and the expired-password reset endpoint.

New menu lifecycle endpoints: read a menu configuration, export its full catalog, duplicate it to a brand or restaurants, and soft-delete it.

Documented product management endpoints on menus: create, update, bulk-update, adjust quantity, duplicate, and delete products.

Documented step management endpoints on menus: read, create, update, convert steps between customization and cross-selling types, duplicate, and delete steps.

Documented category management endpoints on menus: list categories, read a category, assign products to a category, reorder the category layout, and delete a category.

New endpoint to toggle the availability of a whole category on the kiosk or web channel of a menu.

New restaurant image library endpoints: upload an image or MP4 video, update image metadata (rename, focal point, zoom), and soft-delete an image.

New stock management endpoints: restaurant inventory with cursor pagination, stock movement audit trail, per-product timeline, stock settings, and stock deliveries.

Documented consumption mode management endpoints (list, create, update, delete) per restaurant and sales channel.

Documented delivery area endpoints: list areas, replace the full area list of a restaurant, and bind/unbind areas to consumption modes.

Documented the VAT configuration referential endpoint listing selectable operation zones and VAT groups with rates per zone and consumption mode (JSON or CSV).

Documented restaurant detail and legal information endpoints.

Documented restaurant module configuration endpoints (list, read by channel, upsert).

Documented brand update, legal, payment configuration, modules and social network endpoints.

Documented the brand audit history endpoints with filtering and pagination.

Documented the fiscally compliant POS versions referential.

New endpoint to retrieve a single webhook configuration by its ID, including its HMAC secret, event types, and subscribed channels.

Documented the public read-only URSSAF minimum amount endpoints used with the pricing rule isUrssafEnabled flag: current value in effect (current calendar year only, amount 0 means no minimum applicable) and full configuration history.

Order grants now include a taxBreakdowns array, ventilating each grant amount across the VAT rates of the products and fees it applied to (with discountableType and feeType). Useful for VAT reporting and URSSAF compliance.

Documented pricing rules, grants, and entrance fees management endpoints with full CRUD operations and brand-level default policy configuration.

Added coupon management documentation with list, create, update, and delete operations.

Documented cross-selling rules including CRUD, duplication, status toggle, and product listing per brand.

Added SKU management endpoints for brands.

Documented POS operations: access management (roles, groups, users), workslots, POS orders, and shift management.

Added restaurant operations documentation covering zones, table layout, kitchen display, pickup schedules, pickup points, and kiosk configuration.

Documented menu operations including copy products/steps across restaurants and pricing revaluation.

Added POS layout management documentation with read, write, and layout function endpoints.

Documented loyalty program integration: configuration, OAuth flow, member management, rewards & cart, and loyalty cards.

Added location and delivery documentation with address autocomplete, geocoding, place details, and delivery area checks.

Documented multi-restaurant order workflow including preview, create, confirm, get, and receipt endpoints.

Added order fulfillment documentation: pickup points, cart management, and delivery areas.

Documented order management: summary export, cancel with contra entry, and manual payment method options.

Added order statistics and attendance documentation with count by interval and restaurant attendance endpoints.

Documented complete order creation flow: preview, create, confirm payment (Stripe & Adyen), send receipt, and bulk order creation.

Added cursor-based order search and order history endpoints.

Documented payment card management (Stripe) with create, list, and delete operations.

Added order payment and payment methods bulk update documentation.

Documented e-wallet transaction reset (RAZ) including brand-wide reset, per-customer reset, auto-scheduling, rollback, and contact email management.

Added e-wallet transaction creation and balance management endpoints.

Documented webhook configuration and event types for customer, order, and transaction events with HMAC-SHA256 signature verification.

Added brand configuration documentation covering brand groups, legal information, restaurant families, web ordering config, and email whitelisting.

Documented brand and restaurant referential endpoints including brand options, brand customers, student entities, restaurant management, POS devices, and payment methods.

Documented customer data management: e-wallet balance history, customer import, ticket/receipt export, and customer metadata.

Added guest group CRUD documentation including bulk import.

Documented customer credentials and badge management: password reset flows and badge CRUD.

Added customer address management documentation.

Documented customer management endpoints: create, update, find, and customer login.

Added customer hierarchy documentation explaining Group > Section > Sub-Section organizational structure.

Documented e-wallet types, customer balance retrieval, transaction history, and transaction listing.

Added user management documentation: list users, create manager, update user, and restaurant assignments.

Documented order retrieval and listing with filtering by brand, restaurant, customer, dates, channels, and status.

Added ordering workflow overview explaining the preview → create → confirm flow.

Initial API documentation portal launched with authentication, user profiles, brand groups, and catalog/PIM documentation (menus, categories, products, steps, tags, images, real-time availability).

Published getting started guides covering API principles, security, network requirements, error codes, and integration recipes.