tech
Storekeeper

API for developers

Clean REST. Bearer auth. Predictable JSON.

The public API of Storekeeper is a thin, well-shaped REST surface over the platform. One token, flat responses, an OpenAPI spec, and a live reference you can call from the browser. No SDK required — though we generate one for your language anyway.

REST + JSON Bearer token from an API key OpenAPI 3.0 24 endpoints Europe/Amsterdam dates
Open the interactive reference → OpenAPI spec

Auth in three calls

Get a token, send it, done.

Get a key

Your Storekeeper administrator creates one in the Storekeeper app and gives you a client_id and a client_secret. No password, no login endpoint.

Send the token

Add Authorization: Bearer <access_token> to every other request. It has to be a token minted from an API key: a browser session's token is refused here with a 401, whatever role it carries. Trust the expires_in you were handed rather than a number printed anywhere; when it runs out, exchange the key again.

Know who you are

GET /api/me resolves the token to account, roles, and locked location.

# 1. exchange your API key for a token, at Storekeeper — not here
TOKEN=$(curl -s -X POST https://api-$ACCOUNT.storekeepercloud.com/oauth/token \
  -u "$SK_CLIENT_ID:$SK_CLIENT_SECRET" \
  -d grant_type=client_credentials | jq -r .access_token)

# no key yet? then you have no token. The read-only demo account was
# withdrawn in 2026-09, and there is no password endpoint to fall back on.

# 2. call an endpoint
curl -s "https://api-dev.storekeeper.software/api/orders?from=2026-07-01&limit=25" \
  -H "Authorization: Bearer $TOKEN"

# 3. who am i
curl -s https://api-dev.storekeeper.software/api/me \
  -H "Authorization: Bearer $TOKEN"

# 4. server-to-server? skip the browser entirely: exchange an API key
#    at your own account's token endpoint. Nothing is brokered here.
curl -s -X POST https://api-$ACCOUNT.storekeepercloud.com/oauth/token \
  -u "$SK_CLIENT_ID:$SK_CLIENT_SECRET" \
  -d grant_type=client_credentials

The surface

24 endpoints, six groups.

GET/api/me
GET/api/orders
GET/api/orders/{id}/items
GET/api/products
GET/api/product-prices
GET/api/stock
GET/api/customers
GET/api/customer-segments
GET/api/financial-report
GET/api/reports/daily-close
GET/api/reports/product-sales

Plus shops, tax-rates, turnover-groups, payment-methods, and locations to resolve the ids reports emit. Full list in the reference.

Conventions

No surprises.

  • Dates are YYYY-MM-DD in Europe/Amsterdam. Ranges inclusive.
  • Money is decimal euros. _wt = incl. VAT, plain/_ex = excl. VAT.
  • Lists return {count, total, data}; paginated add {start, limit}.
  • Errors are {error, message, status}: 400 / 401 / 404 / 429 / 502.

Access & limits

The rules.

This is the only supported way to connect to Storekeeper. No other integration method is recommended or allowed. Your subscription must cover both the volume of calls you make and the scope you access.

Tokens are short-lived — trust the expires_in you were handed, not a number printed here. There is no renew endpoint: exchange the key again, which is cheap and consumes nothing. Every call acts as you, on your account, within your rights.

/api takes an access token minted from an API key — a browser session's token is a 401 — and request volume is capped per key, per minute, with a separate and tighter ceiling for writes. Every authenticated response carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset, and two more that name the ceiling those numbers belong to: RateLimit-Policy, every ceiling that applies to the key with its quota and window, and RateLimit, the state of the one closest to refusing you next. Over a ceiling the answer is 429 with Retry-After in seconds. Pace off the headers rather than a hard-coded rate — no figure is published, so tuning one never makes this page wrong.

Start building.

The interactive reference lets you authorize and fire real requests from the browser. The guide walks the common flows end to end.

Interactive reference Guide & use cases