ready2order Public API (R2-2026.27.5)

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.