Beurteilen Sie eine Buchhaltungs-API anhand von acht Dingen, die Sie an einem Nachmittag aus ihrer Dokumentation überprüfen können: wie sich ein Aufrufer authentifiziert und gegenüber welchem Mandanten, ob Berechtigungen eingeschränkt sind, ob Schreibvorgänge idempotent sind, ob sie Sie über Änderungen informiert (Webhooks), wie hoch das Rate-Limit ist und wie es fehlschlägt, ob es eine Sandbox gibt, wie ein Fehler aussieht und ob ein KI-Assistent sie nutzen kann, ohne Schaden anrichten zu können. Ein Anbieter, der alle acht mit Konkretem beantwortet, hat über Integrationen nachgedacht; ein Anbieter, der mit „ja“ antwortet, nicht. Diese Seite nennt die Fragen und dann die Antworten von KRONENWERK mit den echten Zahlen und den echten Einschränkungen.
Warum die API mehr entscheidet als die Funktionsliste
Ein Buchhaltungssystem, in das Ihr Produkt schreibt, wird Teil Ihres Produkts. Seine API prägt, wie Sie Kunden und Rechnungen modellieren, wie Sie sich um 3 Uhr nachts von einer fehlgeschlagenen Anfrage erholen und was ein Prüfer sieht, wenn er fragt, welches System eine Buchung erzeugt hat. Nach der Funktionsliste auszuwählen und die API später zu entdecken, ist der Weg, auf dem Integrationen bei einem nächtlichen CSV-Job und einer Person landen, die „es kontrolliert“.
Die acht Kriterien unten sind danach geordnet, wie teuer es ist, sie zu umgehen. Fehlende Idempotenz zum Beispiel lässt sich clientseitig nicht beheben; ein grobes Rate-Limit schon.
Die Bewertungstabelle
Verwenden Sie die mittlere Spalte als Frage an jeden Anbieter; verwenden Sie die rechte Spalte, um die Antwort zu beurteilen.
| Kriterium | Was Sie fragen sollten | So sieht eine gute Antwort aus |
|---|---|---|
| Authentifizierung und Mandantenzuordnung | Wie identifiziert sich eine Anfrage, und woher weiß der Server, für welches Unternehmen sie gilt? | Ein Bearer-Geheimnis, das bei der Ausgabe an genau ein Unternehmen gebunden ist; der Mandant stammt nie aus einem Header oder Pfad, den der Aufrufer kontrolliert; ein Aufruf, der Ihnen sagt, zu welchem Unternehmen ein Schlüssel gehört. |
| Scopes | Kann ein Schlüssel auf Lesen oder auf einen Objekttyp beschränkt werden? | Benannte Scopes je Objekt und je Richtung (Lesen / Schreiben), serverseitig geprüft, wobei Lesen kein Schreiben impliziert. |
| Idempotenz | Was passiert, wenn ich ein POST wiederhole, dessen Antwort ich nie erhalten habe? | Ein Idempotency-Key-Header; gleicher Schlüssel und Body liefert das ursprüngliche Ergebnis; gleicher Schlüssel mit anderem Body wird abgelehnt; eine dokumentierte Lebensdauer des Schlüssels. |
| Webhooks | Wie erfahre ich ohne Polling, dass eine Rechnung bezahlt wurde? | Signierte Zustellungen (HMAC über Zeitstempel und Roh-Body), eine Ereigniskennung zur Deduplizierung, Wiederholungen mit dokumentierter Anzahl, nur HTTPS, keine Weiterleitungen. |
| Rate-Limits | Wie viele Aufrufe, wie gemessen, und was kommt zurück, wenn ich es überschreite? | Ein angegebenes Budget und eine Auffüllrate je Schlüssel; 429 mit Retry-After; die Zahl, nicht „fair use“. |
| Sandbox | Wo teste ich, ohne echte Bücher zu berühren? | Testzugangsdaten, die dieselbe API mit derselben Validierung ansprechen; klare Trennung von Echtdaten. |
| Fehler und Versionierung | Wie sieht ein Fehlschlag aus, und was verspricht eine Version? | JSON mit einem maschinenlesbaren Code plus einem menschenlesbaren Satz; eine Version im Pfad; eine ausdrückliche Regel, was sich innerhalb einer Version ändern darf. |
| MCP für Assistenten | Kann ein KI-Assistent die Bücher lesen, und was kann er nicht? | Ein MCP-Server mit demselben Schlüssel und denselben Scopes; Lesewerkzeuge plus Entwurfswerkzeuge; kein Werkzeug, das Dokumente ausstellt, Mails sendet, Geld bewegt oder Einstellungen ändert. |
Drei Kriterien genauer
Idempotenz ist das eine, das Sie nicht nachrüsten können
Jedes Netzwerk verliert irgendwann eine Antwort. Der IETF-Entwurf für den Header beschreibt den Zweck: nicht-idempotente HTTP-Methoden wie POST oder PATCH „fehlertolerant“ zu machen. Der Entwurf ist abgelaufen, ohne RFC zu werden, aber die Konvention, die er dokumentiert, ist das, was die meisten Zahlungs- und Buchhaltungs-APIs verwenden. Wenn die API eines Anbieters sie nicht kennt, bleibt Ihnen nur, vor jedem Schreibvorgang abzufragen (ein Wettlauf) oder gelegentlich doppelte Kunden und Rechnungen hinzunehmen. Keines von beidem übersteht eine Prüfung gut.
Webhooks: dieselben Regeln wie bei Stripe
Stripes Webhook-Leitfaden ist zum De-facto-Standard geworden und ein guter Maßstab für jede Buchhaltungs-API: Signaturen, um zu „prüfen, dass Webhook-Ereignisse“ vom Absender stammen, Toleranz für Duplikate, weil Endpunkte „gelegentlich dasselbe Ereignis mehr als einmal erhalten“ können, keine garantierte Reihenfolge und ein schnelles 2xx vor jeder aufwendigen Verarbeitung. Fragen Sie den Anbieter, ob seine Zustellungen eine Signatur, einen Zeitstempel und eine Ereigniskennung tragen — und ob die Signatur über den Roh-Body berechnet wird, denn eine Signatur über neu serialisiertes JSON lässt sich nicht zuverlässig prüfen.
MCP: viel lesen, wenig vorbereiten, nichts auslösen
Das Model Context Protocol ist „ein offenes Protokoll, das eine nahtlose Integration zwischen LLM-Anwendungen und externen Datenquellen und Werkzeugen ermöglicht“, mit JSON-RPC-2.0-Nachrichten zwischen Hosts, Clients und Servern. Seine Spezifikation ist ausdrücklich: Werkzeuge „stellen beliebige Codeausführung dar und müssen mit angemessener Vorsicht behandelt werden“, und „Hosts müssen die ausdrückliche Zustimmung des Nutzers einholen, bevor sie ein Werkzeug aufrufen“. Für ein Buchhaltungsjournal bedeutet das einen einfachen Test: Listen Sie die Werkzeuge auf und prüfen Sie, dass keines eine Rechnung ausstellen, ein Dokument senden, Geld bewegen oder eine Einstellung ändern kann. Ein Assistent, der „wer ist überfällig?“ beantworten und eine Rechnung zur Prüfung durch eine Person entwerfen kann, ist nützlich; einer, der sie ausstellen kann, ist ein Risiko.
Wie KRONENWERK jedes Kriterium beantwortet
Die Zahlen unten sind die, die die API heute durchsetzt; die Referenz steht unter der Entwicklerreferenz. API, Webhooks, MCP-Server und Integrationsverzeichnis sind Teil des Enterprise-Plans — siehe Pläne. MIT EINSCHRÄNKUNGEN UNTERSTÜTZT
| Kriterium | KRONENWERK |
|---|---|
| Authentifizierung und Mandantenzuordnung | Bearer-API-Schlüssel, Präfix greif_live_ oder greif_test_, unter https://kronenwerk.org/api/extern/v1. Ein Unternehmen je Schlüssel, bei der Ausgabe festgelegt; kein Header oder Pfad wählt ein Unternehmen aus. GET /me liefert Unternehmen und Scopes. Nur ein Hash des Schlüssels wird gespeichert; ein verlorener Schlüssel wird ersetzt, nicht wiederhergestellt. Siehe Authentifizierung. |
| Scopes | customers:read, customers:write, invoices:read, invoices:write, transactions:read, transactions:write, reports:read, companies:read. Lesen und Schreiben sind getrennte Berechtigungen. |
| Idempotenz | Idempotency-Key bei jedem POST erforderlich. Gleicher Schlüssel und Body: der ursprüngliche Datensatz; gleicher Schlüssel und anderer Body: abgelehnt mit 409 und Code IDEMPOTENZ_KONFLIKT; Schlüssel gelten 24 Stunden. Siehe Idempotenz. |
| Webhooks | Ereignisse invoice.issued, invoice.paid, invoice.cancelled, purchase.recorded, payment.recorded. Header KRONENWERK-Signature (t=…,v1=…, HMAC-SHA256 über t.raw_body, 5 Minuten Toleranz), KRONENWERK-Event-Id, KRONENWERK-Event, KRONENWERK-Delivery, KRONENWERK-Attempt, Idempotency-Key. Nur HTTPS, Wiederholung bis zur Annahme, keine Weiterleitungen. Siehe Webhooks. |
| Rate-Limits | Ein Budget von 240 Anfragen je Schlüssel, kontinuierlich mit etwa zwei pro Sekunde aufgefüllt. Bei Überschreitung kommt 429 mit Retry-After und Code ZU_VIELE_ANFRAGEN zurück. Siehe Grenzen. |
| Sandbox | Ein greif_test_-Schlüssel arbeitet gegen dieselbe API im Testmodus für das Unternehmen, das ihn erstellt hat. Es gibt keinen separaten Sandbox-Host. |
| Fehler und Versionierung | Fehler sind JSON mit einem Maschinencode und einem Satz, z. B. {"fehler": "…", "code": "NICHT_GEFUNDEN"}; der Code ist Teil des Vertrags, der Satz darf umformuliert werden. Die Version steht im Pfad (/v1); innerhalb einer Version dürfen Felder hinzukommen, aber nicht entfernt oder umtypisiert werden, und Codes behalten ihre Bedeutung. Siehe Fehler. |
| MCP | Server unter /api/extern/mcp, Streamable HTTP, derselbe API-Schlüssel. Lesewerkzeuge: 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. Entwurfswerkzeuge: create_invoice_draft, create_transaction, add_transaction_note. Kein Werkzeug stellt eine Rechnung aus, sendet Mails, bewegt Geld oder ändert Einstellungen. Siehe MCP. |
Die vollständige Endpunktliste ist bewusst kurz: GET /me, GET /customers, GET /customers/{id}, POST /customers, GET /invoices, GET /invoices/{number}, POST /invoices/drafts, GET /transactions, POST /transactions, GET /reports/outstanding. Eine Anfrage und ihre Ablehnung sehen so aus:
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"}
Die API wird in Prosa auf der Seite zur Buchhaltungs-API beschrieben; die Sicherheitsbetrachtung steht unter Sicherheit für Entwickler; die weitere Bewertung für europäische Unternehmen — Formate, Umsatzsteuer, Sprachen — steht unter was ein europäisches Unternehmen braucht.
Häufig gestellte Fragen
Reicht ein API-Schlüssel, oder sollte ich auf OAuth bestehen?
Für eine Server-zu-Server-Integration, bei der Sie beide Enden kontrollieren, ist ein eingeschränkter Schlüssel, der an ein Unternehmen gebunden ist, einfacher und nicht weniger sicher. OAuth zählt, wenn Dritte im Namen vieler Ihrer Nutzer handeln; das ist bei einem Unternehmen, das seine eigene App mit seinem eigenen Journal verbindet, nicht der Fall.
Was ist ein angemessenes Rate-Limit für eine Buchhaltungs-API?
Genug für einen Schub zum Monatsende und ein stetiges Rinnsal sonst. Das Budget von KRONENWERK mit 240 Anfragen und einer Auffüllung von etwa zwei pro Sekunde passt zu diesem Muster; wichtiger ist, dass das Limit angegeben ist und dass 429 ein Retry-After trägt.
Warum lässt KRONENWERK die API keine Rechnungen ausstellen?
Weil die Ausstellung eine rechtsgültige Nummer vergibt, die E-Rechnung erzeugt und die USt-IdNr. prüft; das Produkt hält diesen Schritt hinter Validierung und einer Person. Entwürfe über die API, Ausstellung im Produkt.
Kann ich die Sandbox ohne bezahlten Plan nutzen?
Ein Testschlüssel wird innerhalb eines Unternehmens im Enterprise-Plan erstellt; es gibt keinen separaten öffentlichen Sandbox-Host. Siehe Pläne.
Gibt der MCP-Server einem Assistenten Schreibzugriff auf meine Bücher?
Nur auf Entwürfe und Notizen: Er kann einen Rechnungsentwurf oder eine Transaktion zur Prüfung durch eine Person vorbereiten. Er kann nichts ausstellen, senden, bezahlen oder umkonfigurieren.