Error catalog
All errors are JSON with the same three fields. Log the whole body: the message is written for humans and usually names the exact parameter or id that caused it.
{ "error": "bad_request", "message": "Missing required parameter: from", "status": 400 }
A parameter is missing, malformed, or unusable: a missing required from date, a non-numeric id in product_ids, an unknown flag value. The API refuses rather than guessing; a typo in product_ids is a 400, never a silently-full catalog.
React: fix the request. Do not retry unchanged; the same input gives the same 400.
No bearer token, an expired one (tokens live 30 minutes), or one this account cannot use.
React: re-authenticate (POST /api/auth/login or /api/auth/refresh) and retry once. Better: refresh proactively around the 25-minute mark. See Integration patterns.
The id does not exist on this account (an order, customer, product, or location), or the path itself does not exist. Ids are per-account: an order id from one account never resolves on another.
React: treat it as data, not as an outage. If you stored the id earlier, the record was removed or you are calling with the wrong account's token.
Reserved. Rate limiting is being introduced together with API keys; when it activates, responses will carry standard rate-limit headers and this page will document them.
React: build your client to back off on 429 today and you will never notice the change.
A fault in the API layer itself. The response never echoes internals.
React: retry with backoff. If it persists, report it with the timestamp and the path; we log every request and can trace it.
The Storekeeper platform behind the API rejected or failed the call. The message carries the upstream reason when it is safe to share.
React: safe to retry with backoff for reads. If the message names a business reason (an id in use, a missing configuration), fix that instead of retrying.
Timeouts and connection errors without a JSON body mean the request may or may not have been processed. For the read API that is always safe to retry.
Foutencatalogus
Alle fouten zijn JSON met dezelfde drie velden. Log de hele body: de message is voor mensen geschreven en noemt meestal exact de parameter of het id dat de fout veroorzaakte.
{ "error": "bad_request", "message": "Missing required parameter: from", "status": 400 }
Een parameter ontbreekt, is misvormd of onbruikbaar: een ontbrekende verplichte from-datum, een niet-numeriek id in product_ids, een onbekende vlagwaarde. De API weigert liever dan te gokken; een typfout in product_ids is een 400, nooit een stilletjes vol assortiment.
Reactie: herstel het verzoek. Niet ongewijzigd opnieuw proberen; dezelfde invoer geeft dezelfde 400.
Geen bearer-token, een verlopen token (tokens leven 30 minuten), of een token dat dit account niet mag gebruiken.
Reactie: opnieuw inloggen (POST /api/auth/login of /api/auth/refresh) en één keer opnieuw proberen. Beter: ververs proactief rond de 25 minuten. Zie Integratiepatronen.
Het id bestaat niet op dit account (een order, klant, product of locatie), of het pad zelf bestaat niet. Ids zijn per account: een order-id van het ene account resolvet nooit op een ander.
Reactie: behandel het als data, niet als een storing. Had je het id eerder opgeslagen, dan is het record verwijderd of gebruik je het token van het verkeerde account.
Gereserveerd. Rate limiting komt samen met API-sleutels; zodra het actief is dragen responses standaard rate-limit-headers en documenteert deze pagina ze.
Reactie: bouw je client nu al zo dat hij terugschakelt op een 429 en je merkt de verandering nooit.
Een fout in de API-laag zelf. De response lekt nooit interne details.
Reactie: opnieuw proberen met backoff. Blijft het aanhouden, meld het met tijdstip en pad; wij loggen elk verzoek en kunnen het traceren.
Het Storekeeper-platform achter de API weigerde of faalde de aanroep. De message bevat de upstream-reden wanneer die veilig te delen is.
Reactie: voor leesverzoeken veilig om met backoff opnieuw te proberen. Noemt de message een zakelijke reden (een id in gebruik, een ontbrekende configuratie), herstel die dan in plaats van te herhalen.
Timeouts en verbindingsfouten zonder JSON-body betekenen dat het verzoek wel of niet verwerkt kan zijn. Voor de lees-API is opnieuw proberen dan altijd veilig.