Beoordeel een boekhoud-API op acht dingen die u in één namiddag uit de documentatie kunt verifiëren: hoe een aanroeper zich authenticeert en bij welke tenant, of rechten beperkt zijn tot scopes, of writes idempotent zijn, of ze u op de hoogte brengt van wijzigingen (webhooks), wat de rate limit is en hoe ze faalt, of er een sandbox is, hoe een fout eruitziet, en of een AI-assistent ze kan gebruiken zonder schade te kunnen aanrichten. Een leverancier die alle acht met details beantwoordt, heeft over integraties nagedacht; een leverancier die met "ja" antwoordt, niet. Deze pagina geeft de vragen, en daarna de antwoorden van KRONENWERK met de echte cijfers en de echte beperkingen.
Waarom de API meer bepaalt dan de functielijst
Een boekhoudsysteem waarnaar uw product schrijft, wordt onderdeel van uw product. Zijn API bepaalt hoe u klanten en facturen modelleert, hoe u om drie uur 's nachts herstelt van een mislukt verzoek, en wat een auditor ziet wanneer hij vraagt welk systeem een boeking heeft aangemaakt. Kiezen op basis van de functielijst en de API later ontdekken, is hoe integraties eindigen met een nachtelijke csv-job en een persoon die "het controleert".
De acht criteria hieronder zijn gerangschikt naar hoe duur het is om er een omweg omheen te bouwen. Ontbrekende idempotentie bijvoorbeeld kan aan de clientzijde niet worden opgelost; een grove rate limit wel.
De beoordelingstabel
Gebruik de middelste kolom als de vraag die u aan elke leverancier stelt; gebruik de rechterkolom om het antwoord te beoordelen.
| Criterium | Wat u vraagt | Zo ziet een goed antwoord eruit |
|---|---|---|
| Authenticatie en tenancy | Hoe identificeert een verzoek zich, en hoe weet de server op welke onderneming het betrekking heeft? | Een Bearer-geheim dat bij de uitgifte aan precies één onderneming is gebonden; de tenant komt nooit uit een header of pad dat de aanroeper beheert; een aanroep die u vertelt bij welke onderneming een sleutel hoort. |
| Scopes | Kan een sleutel worden beperkt tot lezen, of tot één objecttype? | Benoemde scopes per object en per richting (lezen / schrijven), aan de serverzijde gecontroleerd, waarbij lezen geen schrijven impliceert. |
| Idempotentie | Wat gebeurt er als ik een POST herhaal waarvan ik het antwoord nooit heb ontvangen? | Een Idempotency-Key-header; dezelfde sleutel en body geeft het oorspronkelijke resultaat terug; dezelfde sleutel met een andere body wordt geweigerd; een gedocumenteerde levensduur van sleutels. |
| Webhooks | Hoe verneem ik zonder pollen dat een factuur betaald is? | Ondertekende afleveringen (HMAC over tijdstempel en ruwe body), een event-identificator voor ontdubbeling, nieuwe pogingen met een gedocumenteerd aantal, alleen HTTPS, geen redirects gevolgd. |
| Rate limits | Hoeveel aanroepen, hoe gemeten, en wat komt er terug als ik de limiet overschrijd? | Een vermeld budget en aanvultempo per sleutel; 429 met Retry-After; het getal, niet "fair use". |
| Sandbox | Waar test ik zonder de echte boekhouding te raken? | Testreferenties die dezelfde API met dezelfde validatie aanspreken; duidelijke scheiding van live gegevens. |
| Fouten en versiebeheer | Hoe ziet een mislukking eruit, en wat belooft een versie? | JSON met een machineleesbare code plus een menselijke zin; een versie in het pad; een vermelde regel voor wat binnen een versie mag veranderen. |
| MCP voor assistenten | Kan een AI-assistent de boekhouding lezen, en wat kan hij niet? | Een MCP-server met dezelfde sleutel en scopes; leestools plus concepttools; geen tool die documenten uitreikt, e-mail verstuurt, geld verplaatst of instellingen wijzigt. |
Drie criteria nader bekeken
Idempotentie is het criterium dat u niet achteraf kunt inbouwen
Elk netwerk verliest vroeg of laat een antwoord. Het IETF-ontwerp voor de header beschrijft het doel: niet-idempotente HTTP-methoden zoals POST of PATCH "fault-tolerant" maken. Het ontwerp is verlopen zonder RFC te worden, maar de conventie die het documenteert, is wat de meeste betalings- en boekhoud-API's gebruiken. Als de API van een leverancier ze mist, zijn uw enige opties vóór elke write een query uitvoeren (een race) of af en toe dubbele klanten en facturen aanvaarden. Geen van beide overleeft een audit goed.
Webhooks: dezelfde regels als die van Stripe
De webhookrichtlijnen van Stripe zijn de feitelijke standaard geworden en een goede maatstaf voor elke boekhoud-API: handtekeningen om te "verify that webhook events originate" van de afzender, tolerantie voor duplicaten omdat endpoints "might occasionally receive the same event more than once", geen gegarandeerde volgorde, en een snelle 2xx vóór elke zware verwerking. Vraag de leverancier of zijn afleveringen een handtekening, een tijdstempel en een event-identificator dragen — en of de handtekening over de ruwe body wordt berekend, want een handtekening over opnieuw geserialiseerde JSON kan niet betrouwbaar worden geverifieerd.
MCP: veel lezen, een beetje voorbereiden, niets in gang zetten
Het Model Context Protocol is "an open protocol that enables seamless integration between LLM applications and external data sources and tools", met JSON-RPC 2.0-berichten tussen hosts, clients en servers. De specificatie is expliciet dat tools "represent arbitrary code execution and must be treated with appropriate caution" en dat "hosts must obtain explicit user consent before invoking any tool". Voor een grootboek vertaalt zich dat in een eenvoudige test: som de tools op en controleer of geen ervan een factuur kan uitreiken, een document kan versturen, geld kan verplaatsen of een instelling kan wijzigen. Een assistent die "wie is achterstallig?" kan beantwoorden en een factuur kan voorbereiden die een persoon nakijkt, is nuttig; een die ze kan uitreiken, is een aansprakelijkheidsrisico.
Hoe KRONENWERK elk criterium beantwoordt
De cijfers hieronder zijn die welke de API vandaag afdwingt; de referentie staat op de ontwikkelaarsreferentie. De API, webhooks, MCP-server en integratiecatalogus maken deel uit van het Enterprise-plan — zie plannen. ONDERSTEUND MET BEPERKINGEN
| Criterium | KRONENWERK |
|---|---|
| Authenticatie en tenancy | Bearer-API-sleutel, voorvoegsel greif_live_ of greif_test_, op https://kronenwerk.org/api/extern/v1. Eén onderneming per sleutel, vastgelegd bij de uitgifte; geen header of pad selecteert een onderneming. GET /me geeft de onderneming en de scopes terug. Alleen een hash van de sleutel wordt opgeslagen; een verloren sleutel wordt vervangen, niet hersteld. Zie authenticatie. |
| Scopes | customers:read, customers:write, invoices:read, invoices:write, transactions:read, transactions:write, reports:read, companies:read. Lezen en schrijven zijn afzonderlijke toekenningen. |
| Idempotentie | Idempotency-Key verplicht op elke POST. Dezelfde sleutel en body: het oorspronkelijke record; dezelfde sleutel en een andere body: geweigerd met 409 en code IDEMPOTENZ_KONFLIKT; sleutels blijven 24 uur geldig. Zie idempotentie. |
| Webhooks | Events invoice.issued, invoice.paid, invoice.cancelled, purchase.recorded, payment.recorded. Headers KRONENWERK-Signature (t=…,v1=…, HMAC-SHA256 over t.raw_body, tolerantie van 5 minuten), KRONENWERK-Event-Id, KRONENWERK-Event, KRONENWERK-Delivery, KRONENWERK-Attempt, Idempotency-Key. Alleen HTTPS, opnieuw geprobeerd tot aanvaard, redirects worden niet gevolgd. Zie webhooks. |
| Rate limits | Een budget van 240 verzoeken per sleutel, continu aangevuld met ongeveer twee per seconde. Overschrijding geeft 429 met Retry-After en code ZU_VIELE_ANFRAGEN. Zie limieten. |
| Sandbox | Een greif_test_-sleutel werkt tegen dezelfde API in testmodus voor de onderneming die ze heeft aangemaakt. Er is geen afzonderlijke sandboxhost. |
| Fouten en versiebeheer | Fouten zijn JSON met een machinecode en een zin, bv. {"fehler": "…", "code": "NICHT_GEFUNDEN"}; de code maakt deel uit van het contract, de zin kan worden geherformuleerd. De versie staat in het pad (/v1); binnen een versie mogen velden worden toegevoegd maar niet verwijderd of van type veranderd, en codes behouden hun betekenis. Zie fouten. |
| MCP | Server op /api/extern/mcp, Streamable HTTP, dezelfde API-sleutel. Leestools: get_customer, search_customers, get_invoice, list_invoices, get_transaction, list_transactions, list_receivables, list_payables, get_profit_and_loss, get_balance_sheet, get_business_attention. Concepttools: create_invoice_draft, create_transaction, add_transaction_note. Geen enkele tool reikt een factuur uit, verstuurt e-mail, verplaatst geld of wijzigt instellingen. Zie MCP. |
De volledige lijst van endpoints is bewust kort: GET /me, GET /customers, GET /customers/{id}, POST /customers, GET /invoices, GET /invoices/{number}, POST /invoices/drafts, GET /transactions, POST /transactions, GET /reports/outstanding. Een verzoek en de weigering ervan zien er zo uit:
GET /api/extern/v1/invoices?status=OPEN&size=1 HTTP/1.1
Host: kronenwerk.org
Authorization: Bearer greif_live_…
HTTP/1.1 200 OK
Content-Type: application/json
{"data":[{"number":"R-2026-0001","issuedOn":"2026-04-02","buyer":"Kellermann GmbH",
"currency":"EUR","gross":{"minor":105910,"currency":"EUR"},
"outstanding":{"minor":105910,"currency":"EUR"},"paymentState":"OPEN","overdue":false}],
"page":0,"size":1,"total":1,"more":false}HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json
{"fehler":"…","code":"ZU_VIELE_ANFRAGEN"}De API wordt in proza beschreven op de pagina over de boekhoud-API; de beveiligingsreview staat op beveiliging voor ontwikkelaars; de bredere beoordeling voor Europese ondernemingen — formaten, btw, talen — staat op wat een Europese onderneming nodig heeft.
Veelgestelde vragen
Volstaat een API-sleutel, of moet ik op OAuth aandringen?
Voor een server-naar-serverintegratie waarbij u beide kanten beheert, is een sleutel met scopes die aan één onderneming is gebonden eenvoudiger en niet minder veilig. OAuth is van belang wanneer derden namens veel van uw gebruikers handelen; dat is niet het geval voor een onderneming die haar eigen app met haar eigen grootboek integreert.
Wat is een redelijke rate limit voor een boekhoud-API?
Genoeg voor een piek bij de maandafsluiting en verder een gestage stroom. Het budget van KRONENWERK van 240 verzoeken, aangevuld met ongeveer twee per seconde, past bij dat patroon; belangrijker is dat de limiet vermeld wordt en dat 429 een Retry-After meegeeft.
Waarom laat KRONENWERK de API geen facturen uitreiken?
Omdat het uitreiken een wettelijk nummer toekent, de e-factuur genereert en het btw-nummer controleert; het product houdt die stap achter validatie en een persoon. Concepten via de API, uitreiken in het product.
Kan ik de sandbox gebruiken zonder betaald plan?
Een testsleutel wordt aangemaakt binnen een onderneming in het Enterprise-plan; er is geen afzonderlijke publieke sandboxhost. Zie plannen.
Geeft de MCP-server een assistent schrijftoegang tot mijn boekhouding?
Alleen tot concepten en notities: hij kan een factuurconcept of een transactie voorbereiden die een persoon nakijkt. Hij kan niets uitreiken, versturen, betalen of herconfigureren.
Bronnen
- KRONENWERK developer documentation — geraadpleegd op
- IETF — The Idempotency-Key HTTP Header Field (Internet-Draft, httpapi WG) — geraadpleegd op
- Model Context Protocol — Specification 2025-06-18 — geraadpleegd op
- Stripe documentation — Receive Stripe events in your webhook endpoint — geraadpleegd op