ready2order Public API (R2-2026.30.2)

The ready2order API uses a three-token flow to grant your integration access to a ready2order account. Your integration identifies itself with a Developer Token, requests permission from the account owner, and receives a long-lived Account Token to use for all subsequent requests.

Every API request to account data must include:

Authorization: Bearer <ACCOUNT_TOKEN>

This is a one-time process per account you want to integrate with.

Step 1 — Get your Developer Token

Register at https://api.ready2order.com. Your Developer Token will be emailed to you.

Store it securely — it identifies your integration across all accounts.

Step 2 — Request a Grant Access Token

Call this endpoint using your Developer Token:

POST /v1/developerToken/grantAccessToken
Authorization: Bearer <DEVELOPER_TOKEN>

{
  "callbackUri": "https://your-app.com/callback"
}

callbackUri is optional but strongly recommended (see Step 3).

Response:

{
  "grantAccessToken": "...",
  "grantAccessUri": "https://app.ready2order.com/..."
}

Step 3 — Account owner approves access

Redirect the account owner to the grantAccessUri. They will log in to their ready2order account and click Approve.

With callbackUri — after approval, ready2order redirects the account owner back to your URL:

https://your-app.com/callback?accountToken=<ACCOUNT_TOKEN>&grantAccessToken=<GRANT_ACCESS_TOKEN>&status=approved

The accountToken in that redirect is what you store and use for all future requests.

Without callbackUri — poll for the result instead:

GET /v1/developerToken/grantAccessToken/{grantAccessToken}
Authorization: Bearer <DEVELOPER_TOKEN>

The response will include accountToken once the account owner has approved.

The Grant Access Token expires after 10 minutes. If the account owner does not approve in time, repeat Step 2 to generate a new one.

Some resources support a training mode that keeps test transactions separate from live data. It is handy for staff training and demos where test sales should not show up in reports or fiscal records.

When a cashier puts the POS into training mode, all transactions in that session are flagged as training records and kept separate from live data. On the API side, the trainingMode field on a resource tells you whether it is a training record, and most list endpoints accept a trainingMode query parameter to filter by it.

Products are the items sold at the point of sale. Each product belongs to a product group and carries a price, a VAT rate, and a set of optional features such as stock tracking, variations, and ingredients.

Identifiers

A product supports three optional identifiers alongside its system product_id:

• product_itemnumber: the merchant's own article number, used on labels, in exports, and for stock lookups
• product_barcode: EAN or barcode for scanning at the POS
• product_externalReference: for integrators to store their own system's ID, so you can map between your records and ready2order without storing product_id on your side

Pricing and VAT

product_price is the base price. Set product_priceIncludesVat to true (the default) if that figure is gross, or false if it is net. A VAT rate is required on creation — supply either product_vat as a percentage or product_vat_id referencing a VAT rate.

Customers and customer categories can have individual price overrides managed via the per-customer prices and per-category prices endpoints.

Custom price and quantity

Set product_customPrice: true to let the cashier enter the price manually at checkout, which is useful for open-price items. product_customQuantity: true does the same for the quantity.

Stock

Stock tracking is optional and configured per product. Set product_stock_enabled: true, then use product_stock_value for the current quantity, product_stock_safetyStock for the minimum threshold, and product_stock_reorderLevel for the point at which the system alerts about low inventory. Use the get stock and update stock endpoints to read or update stock figures without touching other product fields.

Product type

product_type is mainly relevant in gastro mode, where it drives printer routing (e.g. kitchen vs. bar). Available values: standard, food, drink, extra, sidedish, variation, ingredient. For standard retail products, use standard.

Variations and ingredients

Variations (selectable add-ons or modifications) and ingredients (component tracking for recipes and partial-unit sales) are enabled per product with product_variations_enabled and product_ingredients_enabled. Both require the corresponding feature to be active on the account.

Keeping a catalogue in sync

The recommended approach is to subscribe to webhooks for product.created and product.updated events. This avoids polling and ensures your system is updated in near real-time without unnecessary requests.

If webhooks are not an option, use the updatedAfter query parameter on list products to fetch only products changed since a given timestamp. Use batch create to create multiple products in one request.