New: every authenticated response now carries two more rate-limit headers alongside the three it already had. RateLimit-Policy lists every ceiling that applies to your API key, each one named, with its quota (q) and its window in seconds (w). RateLimit reports the state of exactly one ceiling — 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. Nothing about the limits themselves changed, and RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset are unchanged and still sent: r and t are the same two numbers as the last two of those. What the pair adds is the name, and that closes a real gap. RateLimit-Remaining always describes whichever counter is closest to refusing you, so across mixed traffic it steps between two of them — a write reports the write counter, the read after it the general one — and the trio carries nothing to say the counter changed, which reads like the server contradicting itself. RateLimit makes that step self-describing. RateLimit-Policy is built from configuration rather than from your request, so it is identical on every authenticated response and even a GET advertises the write ceiling: a client that has only read so far learns that a tighter ceiling is waiting for its first write, instead of discovering it by being refused. Both ride on the 429 as well, where RateLimit names the ceiling that refused, with r=0. The two new headers are the current draft of the IETF rate-limit headers (draft-ietf-httpapi-ratelimit-headers, draft-11); the three you already have are the same work as it stood earlier and are what most HTTP clients and libraries read today. Both sets are sent, so use whichever your stack already understands. Still no figure is published anywhere in the documentation — the ceilings are deployment configuration, and the headers remain the only place a number comes from.

Breaking: /api now accepts only an access token minted from a Storekeeper API key, and the per-key rate limit this page has promised since the key-admin release is enforced. A token minted for a browser session — what GET /loginSso gives a merchant signing in from their backoffice — is refused with 401 on every /api route whatever role it carries, and the message names the fix: create a key at /keys and exchange its client_id and client_secret for an access token at your own account's OAuth token endpoint (client_credentials, RFC 6749 section 4.4). If you were calling /api with a session token, that stops working now; nothing else about the request changes. Pinning the credential down is what makes the limit definable in the first place — every session token carries the same deployment-wide client_id, so "per key" could not even be counted for that half of the traffic. The limit: requests are counted per API key, per minute, and writes (POST, PUT, PATCH, DELETE) have a second, tighter ceiling that they are charged against in addition to the general one. Past a ceiling the answer is 429 Too Many Requests with Retry-After in seconds — wait that long rather than retrying hot, which only spends the next window on refusals too. You do not have to be refused to learn where you stand: every response to an authenticated call now carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset. No figure is published, because the ceilings are deployment configuration and a number printed in documentation would be wrong the day one is tuned; the trade is that a nightly sync is sized by reading RateLimit-Limit off one call instead of copying a rate from a page. Give each integration its own key — sharing one across a fleet spends one budget between them, and revoking one must not take the others down with it.

Breaking: the documentation moved off /api. The interactive reference is now /docs, the spec is /openapi.json (Dutch: /openapi.nl.json), and the guide, recipes, libraries, error catalog, changelog and overview pages lost their /api prefix — /guide, /recipes, /sdks, /errors, /changelog, /business, /technical. The homepage is the site root itself rather than a redirect to one. Health probes moved to /_status/livez, /_status/readyz and /_status/version. Nothing about the API itself changed: the same 25 operations, at the same paths, with the same contracts. The point is that /api now holds those operations and nothing else — documentation and probes used to share the prefix, told apart only by a list somebody had to maintain, and a page added there would have been published to all nine SDKs as an endpoint. Update any bookmark of /api/doc.json to /openapi.json; no redirects are left behind, because a redirect under /api would be the very thing this removes.

New: GET /loginSso now signs you in and lands on /keys, a page where you manage the API keys your integrations authenticate with — create one, roll its secret, revoke it. It used to answer a JSON document with an access token in it, which is a breaking change to that route, though nothing in the browser flow depended on that body. A key's client_secret is shown exactly once, on the screen that mints it: Storekeeper keeps only a hash, so nobody can show it again. Give each integration its own key — the rate limit is per key, and revoking one must not take the others down with it. This closes the gap the previous entry left open: machine callers were told to use an API key while nothing in the product issued one. Also: every script, stylesheet and font this site serves now comes from this origin instead of a CDN. The pages where you paste or read a credential are the ones that matter, and a third party inside those pages can read what you type into them.

Breaking: POST /api/auth/refresh is removed and POST /api/auth/logout moves to POST /logout. Refresh had no caller worth keeping: renewing a machine API with a browser-session cookie was the wrong shape, and an API key is the right one. An unattended integration should now ask its Storekeeper administrator for an API key and exchange it for an access token at its own account's OAuth token endpoint (client_credentials, RFC 6749 section 4.4, discoverable at https://api-<account>.storekeepercloud.com/.well-known/oauth-authorization-server) — that exchange happens at Storekeeper, and this API never sees or brokers the secret. An interactive browser session now lasts exactly one access token: open the app from your backoffice again when it expires. Logout moved because it is part of that browser session rather than the machine API; the sk_rt cookie's Path moved with it and is now scoped to the single route that reads it. Both auth POSTs therefore leave the published spec and the nine generated SDKs, which no longer document any write operation at all. Nothing was deployed and no integrator held a session, so no running integration stops working.

Breaking: the read-only demo token is withdrawn. POST /api/auth/demo is removed, and with it the last route that took a password and the last credential anyone could mint from a terminal. Every /api/ call now authenticates with the same ConnectedApp access token: open the app from your Storekeeper backoffice, land on GET /loginSso, and roll a fresh token with the HttpOnly sk_rt cookie at POST /api/auth/refresh. Starting a session needs a browser — there is no anonymous, demo or long-lived credential left to fall back on — so the guide, the SDK quickstarts and the reference page now all begin from a token you already hold rather than minting one. The demo account was shared and read-only, so nothing private was exposed by it and no integration holding a real session stops working.

Breaking: GET /api/me no longer returns token.read_only. The field answered "will every write be refused before the route runs", and only the read-only demo token — withdrawn in the entry above — ever made it true. With that credential gone the field could only ever say false, and a standing promise read out of a constant is worse than an absent field: a client branching on if (!me.token.read_only) would be branching on something that can never change. token.kind stays, but access_token is now its only value. authorization.gated stays too and is always true: the capability gate applies to every caller, with no exemption. The shape where gated was false and capabilities was null — meaning "not applicable", not "holds nothing" — is gone with the credential it described. Read what you may do from authorization.capabilities, which is a real answer for every caller: an empty map means a role that holds nothing.

Breaking: POST /api/auth/login is removed. A merchant now opens the app from their Storekeeper backoffice, which lands on GET /loginSso?t= and returns {access_token, token_type, expires_in} plus an HttpOnly sk_rt refresh cookie scoped to /api/auth. POST /api/auth/refresh keeps its path but replaces its contract: no body, no bearer, just that cookie. New POST /api/auth/logout revokes the refresh and access tokens upstream and clears the cookie — the first real revocation this API has had. Keep sending Authorization: Bearer <access_token> on every other call; only how you obtain it changed. POST /api/auth/demo is unchanged, and because it still signs in with a password, password handling is not gone from the API — only from the login route. (That last sentence records what was true of this release. POST /api/auth/demo was itself withdrawn on 2026-09-16 — see the entry above — so password handling is now gone from the API entirely.)

Breaking: long-lived sk_live_ API keys are withdrawn. No key was ever issued, and the commands that minted, listed and revoked them are gone. Every integration — interactive or unattended — now starts at GET /loginSso and refreshes its access token with the HttpOnly sk_rt cookie. One consequence worth planning around: POST /api/webhooks needs a durable Storekeeper credential to poll with, the API key was the only one that carried one, so subscriptions cannot be created until the SSO path gains one. Ask your Storekeeper contact if you were relying on either.

Breaking: outbound webhooks are withdrawn. POST /api/webhooks and the list, get, delete and test endpoints are removed, together with the dispatcher behind them. No subscription was ever created — since sk_live_ keys were withdrawn nothing could create one — so no integration stops working. Push delivery is being reworked and will come back as a new design; until then poll the delta feeds, GET /api/orders/delta and GET /api/products/delta, which are the same feeds the dispatcher polled.

Webhooks: POST /api/webhooks subscribes an HTTPS endpoint to order.updated and product.updated events. Deliveries are HMAC-signed batches, at-least-once, with a test ping endpoint and per-subscription delivery log. (Withdrawn on 2026-09-16 — see the entry above.)

Long-lived API keys (sk_live_) for server integrations: no more 30-minute token refresh. Keys are user-bound, provisioned by Storekeeper, shown once and stored hashed. Ask your Storekeeper contact for one. (Withdrawn on 2026-09-16 — see the entry above.)

New delta endpoints for incremental sync: GET /api/orders/delta and GET /api/products/delta. Start from a `since` timestamp, then follow the opaque `next_cursor` to pull only what changed. No more full drains.

Launched the recipe cookbook at /recipes: task-oriented walkthroughs extracted from production integrations, plus this error catalog and changelog.

All marketing and guide pages are bilingual (EN/NL). New /sdks page with 9 downloadable, generated SDKs (PHP, TypeScript, Python, C#, Java, Go, Rust, Kotlin, Swift). Clean operationIds across the spec.

The surface grew from 8 to 24 endpoints: orders, products, prices, stock, customers, segments, and the reports family (payments, daily close, product sales). New human guide at /guide.

Financial report turnover rows now carry product_group_code next to product_group_id, so ledger mapping can key on your own codes.

New reference endpoints: /api/payment-methods (stable type_alias per method type) and /api/turnover-groups.

Nieuw: elk geauthenticeerd antwoord draagt nu twee extra limiet-headers naast de drie die er al waren. RateLimit-Policy somt elk plafond op dat voor jouw API-sleutel geldt, elk met een naam, een quotum (q) en een venster in seconden (w). RateLimit geeft de stand van precies één plafond — het plafond dat je als eerste gaat weigeren — en noemt erbij welk, met r voor wat er over is en t voor de seconden tot het opnieuw begint. Er zijn twee namen: general en write. Aan de limieten zelf verandert niets, en RateLimit-Limit, RateLimit-Remaining en RateLimit-Reset blijven ongewijzigd en worden nog steeds meegestuurd: r en t zijn dezelfde twee getallen als de laatste twee daarvan. Wat het paar toevoegt is de naam, en daarmee is een echt gat gedicht. RateLimit-Remaining beschrijft altijd de teller die je als eerste gaat weigeren, dus bij gemengd verkeer stapt hij tussen twee tellers — een schrijfactie rapporteert de schrijfteller, de leesactie erna de algemene — en aan het drietal is niet te zien dat de teller wisselde, wat leest als een server die zichzelf tegenspreekt. RateLimit maakt die stap zelfverklarend. RateLimit-Policy wordt uit de configuratie opgebouwd en niet uit je verzoek, dus hij is op elk geauthenticeerd antwoord hetzelfde en ook een GET kondigt het schrijfplafond aan: een client die tot nu toe alleen las, weet daardoor dat er een strenger plafond op zijn eerste schrijfactie wacht in plaats van dat hij het ontdekt door geweigerd te worden. Beide zitten ook op de 429, waar RateLimit het plafond noemt dat weigerde, met r=0. De twee nieuwe headers zijn de huidige versie van de IETF-limietheaders (draft-ietf-httpapi-ratelimit-headers, draft-11); de drie die je al had zijn hetzelfde werk in een eerdere versie en zijn wat de meeste HTTP-clients en libraries vandaag lezen. Beide sets worden meegestuurd, dus gebruik wat je stack al kent. Er staat nog steeds nergens in de documentatie een getal — de plafonds zijn deployment-configuratie, en de headers blijven de enige plek waar een getal vandaan komt.

Breaking: /api accepteert voortaan alleen een access token dat uit een Storekeeper API-sleutel is aangemaakt, en de limiet per sleutel die deze pagina sinds de sleutelbeheer-melding belooft, wordt nu afgedwongen. Een token dat voor een browsersessie is aangemaakt — wat GET /loginSso een merchant geeft die vanuit de backoffice inlogt — wordt op elke /api-route geweigerd met een 401, welke rol het ook draagt, en de message noemt de oplossing: maak een sleutel aan op /keys en wissel de client_id en client_secret in voor een access token bij het OAuth token-endpoint van je eigen account (client_credentials, RFC 6749 sectie 4.4). Riep je /api aan met een sessietoken, dan stopt dat nu; aan het verzoek zelf verandert verder niets. Die credential vastleggen is precies wat de limiet definieerbaar maakt — elk sessietoken draagt dezelfde deployment-brede client_id, dus "per sleutel" viel voor die helft van het verkeer niet eens te tellen. De limiet: verzoeken worden per API-sleutel per minuut geteld, en schrijfacties (POST, PUT, PATCH, DELETE) hebben een tweede, strenger plafond waarop ze bovenop de algemene teller worden afgeschreven. Boven een plafond is het antwoord 429 Too Many Requests met Retry-After in seconden — wacht die tijd af in plaats van heet te herhalen, want dat verbruikt alleen ook het volgende venster aan weigeringen. Je hoeft niet geweigerd te worden om te weten waar je staat: elk antwoord op een geauthenticeerde aanroep draagt nu RateLimit-Limit, RateLimit-Remaining en RateLimit-Reset. Er wordt geen getal gepubliceerd, want de plafonds zijn deployment-configuratie en een getal in documentatie zou fout zijn op de dag dat er één wordt bijgesteld; de keerzijde is dat je een nachtelijke sync maat door RateLimit-Limit van één aanroep af te lezen in plaats van een tempo van een pagina over te nemen. Geef elke koppeling een eigen sleutel — er een delen over een vloot betekent één budget samen opmaken, en één intrekken mag de andere niet meenemen.

Breaking: de documentatie is van /api af. De interactieve referentie is nu /docs, de spec is /openapi.json (Nederlands: /openapi.nl.json), en de gids, recepten, libraries, foutencatalogus, changelog en overzichtspagina's zijn hun /api-prefix kwijt — /guide, /recipes, /sdks, /errors, /changelog, /business, /technical. De homepage is de root van de site zelf in plaats van een doorverwijzing daarnaartoe. Healthchecks verhuisden naar /_status/livez, /_status/readyz en /_status/version. Aan de API zelf verandert niets: dezelfde 25 operaties, op dezelfde paden, met dezelfde contracten. Waar het om gaat is dat /api nu alleen nog die operaties bevat — documentatie en healthchecks deelden de prefix en werden alleen uit elkaar gehouden door een lijst die iemand moest bijhouden, en een pagina die daar werd toegevoegd zou als endpoint in alle negen SDK's zijn gepubliceerd. Pas een bookmark van /api/doc.json aan naar /openapi.json; er blijven geen redirects achter, want een redirect onder /api zou precies zijn wat hier wordt weggehaald.

Nieuw: GET /loginSso logt je nu in en landt op /keys, een pagina waar je de API-sleutels beheert waarmee je koppelingen zich authenticeren — aanmaken, secret vervangen, intrekken. Die route gaf eerder een JSON-document met een access token terug; dat is een breaking change, al hing er in de browserflow niets van dat antwoord af. Het client_secret van een sleutel zie je precies één keer, op het scherm dat hem aanmaakt: Storekeeper bewaart alleen een hash, dus niemand kan hem opnieuw tonen. Geef elke koppeling een eigen sleutel — de limiet geldt per sleutel, en één intrekken mag de andere niet meenemen. Hiermee is het gat uit de vorige melding gedicht: machinekoppelingen kregen te horen dat ze een API-sleutel moesten gebruiken terwijl niets in het product er een uitgaf. Verder: elk script, elke stylesheet en elk lettertype van deze site komt nu van deze origin in plaats van een CDN. Het gaat om de pagina's waar je een credential plakt of afleest: een derde partij binnen zo'n pagina kan lezen wat je erin typt.

Breaking: POST /api/auth/refresh is verwijderd en POST /api/auth/logout verhuist naar POST /logout. Verversen had geen aanroeper die het waard was: een machine-API verversen met een browsercookie was de verkeerde vorm, en een API-sleutel de juiste. Een onbemande koppeling vraagt haar Storekeeper-beheerder voortaan om een API-sleutel en wisselt die in voor een access token bij het OAuth token-endpoint van haar eigen account (client_credentials, RFC 6749 sectie 4.4, op te zoeken via https://api-<account>.storekeepercloud.com/.well-known/oauth-authorization-server) — dat inwisselen gebeurt bij Storekeeper, en deze API ziet of bemiddelt het secret nooit. Een interactieve browsersessie duurt nu precies één access token: open de app opnieuw vanuit je backoffice als hij verloopt. Logout verhuisde omdat hij bij die browsersessie hoort en niet bij de machine-API; de Path van de sk_rt-cookie verhuisde mee en dekt nu alleen nog de ene route die hem leest. Beide auth-POST's verdwijnen daarmee uit de gepubliceerde spec en de negen gegenereerde SDK's, die nu helemaal geen schrijfbewerking meer documenteren. Er was niets uitgerold en geen integrator had een sessie, dus er stopt geen enkele draaiende koppeling.

Breaking: het alleen-lezen demotoken is ingetrokken. POST /api/auth/demo is verwijderd, en daarmee de laatste route die een wachtwoord aannam en de laatste credential die je vanuit een terminal kon aanmaken. Elke /api/-aanroep authenticeert nu met hetzelfde ConnectedApp-access token: open de app vanuit je Storekeeper-backoffice, land op GET /loginSso en haal een vers token met de HttpOnly sk_rt-cookie via POST /api/auth/refresh. Een sessie starten vraagt een browser — er is geen anoniem, demo- of langlevend alternatief meer om op terug te vallen — dus de gids, de SDK-quickstarts en de referentiepagina beginnen nu allemaal bij een token dat je al hebt in plaats van er een aan te maken. Het demo-account was gedeeld en alleen-lezen, dus er is niets vertrouwelijks mee blootgelegd en geen koppeling met een echte sessie stopt met werken.

Breaking: GET /api/me geeft token.read_only niet meer terug. Dat veld beantwoordde de vraag "wordt elke schrijfactie geweigerd voordat de route draait", en alleen het alleen-lezen demotoken — ingetrokken in de melding hierboven — maakte het ooit waar. Nu die credential weg is kon het veld alleen nog false zeggen, en een blijvende belofte die uit een constante wordt gelezen is erger dan een veld dat er niet is: een client die vertakt op if (!me.token.read_only) vertakt op iets dat nooit meer verandert. token.kind blijft, maar heeft nog maar één waarde: access_token. authorization.gated blijft ook en is altijd true: de capability-gate geldt voor elke aanroeper, zonder uitzondering. De vorm waarin gated false was en capabilities null — wat "niet van toepassing" betekende, niet "heeft niets" — is verdwenen met de credential die zij beschreef. Lees uit authorization.capabilities wat je mag: dat is voor elke aanroeper een echt antwoord, en een lege map betekent een rol die niets heeft.

Breaking: POST /api/auth/login is verwijderd. Een merchant opent de app voortaan vanuit de Storekeeper-backoffice, landt op GET /loginSso?t= en krijgt {access_token, token_type, expires_in} plus een HttpOnly sk_rt-verversingscookie op /api/auth. POST /api/auth/refresh houdt zijn pad maar krijgt een nieuw contract: geen body, geen bearer, alleen die cookie. Nieuw is POST /api/auth/logout, dat de verversings- en accesstokens bij Storekeeper intrekt en de cookie wist — de eerste echte intrekking die deze API heeft. Blijf Authorization: Bearer <access_token> meesturen bij elke andere aanroep; alleen de manier waarop je hem krijgt is veranderd. POST /api/auth/demo is ongewijzigd, en omdat die nog met een wachtwoord inlogt is wachtwoordafhandeling niet uit de API verdwenen — alleen uit de login-route. (Die laatste zin beschrijft wat waar was bij deze release. POST /api/auth/demo is op 2026-09-16 zelf ingetrokken — zie de melding hierboven — dus wachtwoordafhandeling is nu volledig uit de API verdwenen.)

Breaking: langlevende sk_live_-API-sleutels zijn ingetrokken. Er is er nooit een uitgegeven, en de commando's die ze aanmaakten, toonden en introkken zijn verwijderd. Elke koppeling — interactief of onbemand — begint nu bij GET /loginSso en ververst haar access token met de HttpOnly sk_rt-cookie. Eén gevolg om rekening mee te houden: POST /api/webhooks heeft een duurzame Storekeeper-credential nodig om mee te pollen, en alleen de API-sleutel droeg die, dus abonnementen kunnen niet worden aangemaakt totdat de SSO-route er een krijgt. Vraag je Storekeeper-contact als je op een van beide vertrouwde.

Breaking: uitgaande webhooks zijn ingetrokken. POST /api/webhooks en de lijst-, ophaal-, verwijder- en testendpoints zijn verwijderd, samen met de dispatcher erachter. Er is nooit een abonnement aangemaakt — sinds sk_live_-sleutels werden ingetrokken kon dat ook niet meer — dus er stopt geen enkele koppeling met werken. Pushbezorging wordt herzien en komt terug als een nieuw ontwerp; poll tot die tijd de delta-feeds, GET /api/orders/delta en GET /api/products/delta, dezelfde feeds die de dispatcher pollde.

Webhooks: POST /api/webhooks abonneert een HTTPS-endpoint op order.updated- en product.updated-events. Leveringen zijn HMAC-gesigneerde batches, minimaal eenmalig bezorgd, met een test-ping-endpoint en een leveringslog per abonnement. (Ingetrokken op 2026-09-16 — zie de melding hierboven.)

Langlevende API-sleutels (sk_live_) voor serverintegraties: geen tokenverversing elke 30 minuten meer. Sleutels zijn gebruikersgebonden, uitgegeven door Storekeeper, worden eenmalig getoond en gehasht opgeslagen. Vraag je Storekeeper-contact om een sleutel. (Ingetrokken op 2026-09-16 — zie de melding hierboven.)

Nieuwe delta-endpoints voor incrementele synchronisatie: GET /api/orders/delta en GET /api/products/delta. Begin met een `since`-tijdstempel en volg daarna de opake `next_cursor` om alleen de wijzigingen op te halen. Geen volledige exports meer nodig.

Receptenkookboek gelanceerd op /recipes: taakgerichte walkthroughs uit productie-integraties, plus deze foutencatalogus en changelog.

Alle marketing- en gidspagina's zijn tweetalig (EN/NL). Nieuwe /sdks-pagina met 9 downloadbare, gegenereerde SDK's (PHP, TypeScript, Python, C#, Java, Go, Rust, Kotlin, Swift). Nette operationIds in de hele spec.

Het oppervlak groeide van 8 naar 24 endpoints: orders, producten, prijzen, voorraad, klanten, segmenten en de rapportenfamilie (betalingen, dagafsluiting, productverkoop). Nieuwe gids op /guide.

Omzetregels in het financieel rapport bevatten nu product_group_code naast product_group_id, zodat grootboekmapping op je eigen codes kan sleutelen.

Nieuwe referentie-endpoints: /api/payment-methods (stabiele type_alias per methodetype) en /api/turnover-groups.