What is Storekeeper?

Storekeeper is a commerce platform for retail and hospitality: a point of sale (POS), a webshop, a back office, inventory and stock control, customer management, and invoicing, all on one account. Shops, bakeries, delis, and multi-location franchises use it to run day-to-day trading.

Storekeeper runs the entire retail stack for a business. This API is how you read and work with that account's data from the outside, over plain HTTPS and JSON, on your own schedule.

What is this API?

api-dev.storekeeper.software is the public API of Storekeeper: the supported, recommended, and only permitted way to connect to a Storekeeper account programmatically. No other integration method is allowed. It authenticates you once, then returns flat, predictable JSON. It holds no database of its own: your bearer token is an encrypted blob of your Storekeeper credentials, so every call acts as you, on your account.

Use cases

Getting started

Every endpoint (except auth and these docs) needs a bearer token. Three steps:

1. Get a token

There is no password endpoint. Ask your Storekeeper administrator for an API key: they create one in the Storekeeper app and hand you a client_id and a client_secret. You exchange those for a short-lived access token at your own account's OAuth endpoint — client_credentials, RFC 6749 §4.4, which every stock OAuth client library already speaks. That exchange happens at Storekeeper, not here: this API never sees or brokers your secret.

# where your token comes from — one call, repeatable, nothing consumed
curl -s -X POST https://api-$ACCOUNT.storekeepercloud.com/oauth/token \
  -u "$SK_CLIENT_ID:$SK_CLIENT_SECRET" \
  -d grant_type=client_credentials
# { "access_token": "...", "token_type": "Bearer", "expires_in": 900 }

2. Call an endpoint

TOKEN="..."   # the token from step 1
curl -s "https://api-dev.storekeeper.software/api/orders?from=2026-07-01&to=2026-07-22&limit=25" \
  -H "Authorization: Bearer $TOKEN"

3. Know who you are

curl -s https://api-dev.storekeeper.software/api/me -H "Authorization: Bearer $TOKEN"
# returns account, token expiry, user identity, roles, locked location

Conventions

• Dates are YYYY-MM-DD in the Europe/Amsterdam timezone. Ranges are inclusive.
• Money is decimal euros. _wt is incl. VAT (Dutch met). Plain or _ex is excl. VAT.
• Lists return {count, total, data}. Paginated lists add {start, limit}, so you drive paging (pass start and limit). A truncated flag appears where a hard ceiling was hit.
• Errors are JSON {error, message, status}: 400 bad input, 401 auth, 404 not found, 429 over the rate limit, 502 upstream Storekeeper error.

Limits

Every /api call authenticates with an access token minted from an API key — a browser session's token is refused with a 401 that names the fix — and that key is what your request volume is counted against.

• The ceiling is per API key, per minute. One key is for one integration: sharing a key across a fleet of workers spends one budget between them, and adding workers on the same key makes you slower, not faster.
• Writes are limited separately and more tightly than reads. A POST, PUT, PATCH or DELETE is charged against both the write counter and the general one.
• Past a ceiling the answer is 429 Too Many Requests with Retry-After in seconds. Wait that long and continue; retrying hot spends the next window on refusals too. See the error catalog.
• Every authenticated response carries the numbers — RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset (seconds until the window rolls). Read RateLimit-Remaining and slow down before it reaches zero. The three always describe one ceiling: the one closest to refusing you next. On a write that is usually the write ceiling, so the number drops when you write and rises again when you read — it steps between two ceilings rather than counting down as one budget. Treat each response's trio on its own; do not infer your rate from the difference between two of them.
• Two further headers name the ceiling those numbers belong to. RateLimit-Policy lists every ceiling that applies to your key, each one named, with its quota (q) and its window in seconds (w). RateLimit reports the state of exactly one of them — the one closest to refusing you next — and says which, with r for what is left and t for the seconds until it resets. There are two names, general and write.
• Read them this way. RateLimit-Policy is built from configuration alone, so it is the same on every authenticated response: a GET advertises the write ceiling too, which is how you find out a tighter one exists before your first write rather than on it. r and t are the same two numbers as RateLimit-Remaining and RateLimit-Reset — what RateLimit adds is the name, which is what makes the step above self-describing instead of looking like the server contradicting itself. On a 429 it names the ceiling that refused, with r=0. All five ride on every authenticated response, so use whichever pair or trio your HTTP client already understands.

Resolving ids

Reports return raw Storekeeper ids. Resolve them to names with the reference endpoints:

Endpoint catalog

Try it live in the interactive reference