Skip to content

Public API · Restaurant infrastructure

Make every restaurant system speak the same language.

Build ordering, payments, loyalty, catalog, and real-time events against one documented contract, from the first request to service at scale.

Start integrating Explore endpoints
api.innovorder.fr
Restaurant network live flow
GET/v1/orders
Response DTO 200 OK
{
  "status": 200,
  "data": {
    "omnichannelOrders": [{
      "status": "PAID",
      "items": [ ... ],
      "totalPriceWithTaxIncluded": 1850,
      ...
    }]
  }
}

Choose your entry point

Get from intent to request.

START

Understand the contract

Authentication, API principles, security, and your first request.

REFERENCE

Find an endpoint

Requests, parameters, and production-shaped response examples.

RECIPES

Build a complete flow

Follow a real integration from sign-in to service.

Change feed

Latest updates.

View all
changedAug 14

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.

fixedAug 14

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.

changedAug 13

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.

changedAug 13

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.

changedAug 12

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.