Bistrosoft Developers
Your restaurant's data, available over an API
Catalog, sales, payments and cash for every one of your shops, in JSON and under the same rules in every country we operate in.
Products, categories, combos and menus: the structure everything else rests on. You can read it and write it.
Transactions APISales, payments and cash movements, line by line. Read-only.
Authorization APIIssues the access tokens the other two need, from your API key and secret. This is where you start.
How it works
A REST API over HTTPS. You request a token, send it in the header and read JSON. No mandatory SDK and no webhooks to configure to get started.
| Authentication | API key and secret with OAuth2 client_credentials for the Catalog API and Transactions API v2. Transactions API v1, now discontinued, uses BistroWeb username and password |
| Format | JSON in request and response. Dates in ISO 8601 |
| Rate limit | 40 calls per minute per user, shared. Going over returns 429 |
| Environments | Preproduction and production, with separate hosts and credentials per country |
Your first call
Two requests: you exchange your API key and secret for an access token, then use that token to read the sales. Credentials come from the Developers section of BistroWeb.
# 1. Access token (lasts an hour; reuse it until it expires)
curl --request POST \
--url 'https://preprod-ar-apigw.bistrosoft.com/oauth/oauth/token' \
--header 'content-type: application/x-www-form-urlencoded' \
--data grant_type=client_credentials \
--data client_id=<your-api-key> \
--data client_secret=<your-secret> \
--data scope=transactions.read
# 2. The sales for a period
curl --request GET \
--url 'https://preprod-ar-apigw-oauth.bistrosoft.com/transactions/sales?From=2026-08-01T00:00:00Z&To=2026-08-16T00:00:00Z' \
--header 'Authorization: Bearer <access-token>'
The repeated /oauth in the first request is not a typo: the first one tells the
gateway which service to reach, the second is the service's own route.
If you are still on Transactions API v1
It is discontinued — new integrations should use v2 above — but it still works. It authenticates with BistroWeb username and password and returns a 48-hour JWT:
curl --request GET \
--url 'https://preprod-ar-apigw.bistrosoft.com/bistroapi/api/v1.0/sales?From=2026-08-01T00:00:00Z&To=2026-08-16T00:00:00Z' \
--header 'Authorization: Bearer <your-token>'
What to know before you start
The Transactions API token lasts two days and there is no refresh
POST /api/v1.0/Token returns a JWT that expires in 48 hours. There is no
refresh endpoint: when it expires you request a new one with the same
credentials. A nightly job has to request a token on every run.
The 40 calls per minute limit is shared
The four query endpoints share 40 requests per minute per user — not 40 each. Switching endpoints does not dodge the limit.
What you see depends on your user
The token carries the shop_code values enabled for your user and the API
filters by them. Asking for a shop that is not yours returns empty or 403,
never another customer's data.
One host per country
Each country has its own host and its own data: Argentina, Mexico and Spain are separate environments, with no global endpoint joining them. The country picker in the top bar switches the host the examples are built against, and the one used when you try an endpoint from here.
You can hand this link to your software provider: everything they need to integrate is here.