[Innovorder API documentation home](https://developers.innovorder.io/index.md)

[Docs](https://developers.innovorder.io/docs/getting-started/introduction.md) [Changelog](https://developers.innovorder.io/changelog.md) [Backoffice](https://backoffice.innovorder.fr) [Open docs](https://developers.innovorder.io/docs/getting-started/introduction.md)

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](https://developers.innovorder.io/docs/getting-started/introduction.md)  [Explore endpoints](https://developers.innovorder.io/docs/orders/orders-retrieve.md)

 api.innovorder.fr 

 Restaurant network   live flow 

1.   POS 
    
2.   Order Pad 
    
3.   Kiosk 
    
4.   Online Ordering 
    
5.   QR Code at table 
    
6.   Tray Scan 
    
7.   Connected Fridges 
    
8.   Vending Machines 
    
9.   Marketplaces (Deliveroo, UberEats, ...) 
    
10.   Autonomous Store 
     
11.   Your custom app\* 
     

 API 

1.   Kitchen Display (KDS) 
    
2.   Order Display (ODS) 
    
3.   Stock Management 
    
4.   Loyalty 
    
5.   Accounting 
    
6.   Data & BI 
    
7.   Hooks 
    

 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.

 Pick the path that matches your task 

[START Understand the contract Authentication, API principles, security, and your first request.](https://developers.innovorder.io/docs/getting-started/introduction.md)

[REFERENCE Find an endpoint Requests, parameters, and production-shaped response examples.](https://developers.innovorder.io/docs/authentication/authentication.md)

[RECIPES Build a complete flow Follow a real integration from sign-in to service.](https://developers.innovorder.io/docs/guides/guide-guest-app-integration.md)

API surface

## One contract, every service.

[Orders Create · track · refund](https://developers.innovorder.io/docs/orders/orders-retrieve.md)

[Customers Profiles · groups · badges](https://developers.innovorder.io/docs/customers/customers-manage.md)

[Payments Cards · e-wallet · Stripe](https://developers.innovorder.io/docs/payments/cards-stripe.md)

[Catalog Menus · products · availability](https://developers.innovorder.io/docs/catalog/pim-overview.md)

[Webhooks Orders · accounts · transactions](https://developers.innovorder.io/docs/webhooks/webhooks-overview.md)

[Promotions Coupons · rules · grants](https://developers.innovorder.io/docs/promotions-and-pricing/pricing-rules.md)

Change feed

## Latest updates.

[View all](https://developers.innovorder.io/changelog.md)

 changed  Aug 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.

 fixed  Aug 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.

 changed  Aug 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.

 changed  Aug 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.

 changed  Aug 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.

[© 2026 Innovorder SAS](https://www.innovorder.com)

Built for teams shipping restaurant infrastructure