Die API ist das Produkt.
Fünf Aufrufe von der leeren Organisation bis zur ersten konformen Rechnung. Ein Datenmodell für Finance, Engineering und Ops - dokumentiert, versioniert, replay-sicher.
Fünf Aufrufe bis zur ersten Rechnung.
Kein Einrichtungsassistent, keine Klickstrecken. Alles, was Kontier kann, ist ein API-Aufruf - das hier ist der kürzeste Weg.
- 01
customer.createdKunde anlegen
customer_type steuert die Steuerbehandlung. Für BUSINESS in der EU ist die USt-ID Pflicht - die VIES-Prüfung läuft automatisch.
terminalcurl -X POST https://api.kontier.eu/v1/customers \ -H "Authorization: Bearer sk_test_..." \ -H "Idempotency-Key: 7f3c9a1e" \ -d '{"name":"Acme GmbH","customer_type":"BUSINESS", "billing_address":{"country":"DE"}, "tax_identifiers":{"vat":"DE123456789"}}'→ 201 · customer.created · VIES: valid
- 02
product.createdProdukt definieren
Die abrechenbare Einheit. pricing_model bestimmt, wie Staffeln später rechnen - VOLUME, STAIRCASE oder PACKAGE.
terminalcurl -X POST https://api.kontier.eu/v1/products \ -H "Idempotency-Key: 2b81d4f0" \ -d '{"name":"API Platform","pricing_model":"STAIRCASE", "tax_category":"STANDARD"}'→ 201 · product.created
- 03
plan.createdPlan versionieren
Der Plan bündelt Produkte und Preise. Jede Veröffentlichung erzeugt eine ganzzahlige plan_version - Subscriptions pinnen sie.
terminalcurl -X POST https://api.kontier.eu/v1/plans \ -H "Idempotency-Key: 9c02aa17" \ -d '{"name":"Pro"}'# dann: POST /v1/plans/{id}/products→ 201 · plan.created · plan_version: 1
- 04
subscription.activatedSubscription starten
Ohne items erbt die Subscription den Snapshot der Plan-Version. Trial, Proration und SEPA-Mandat inklusive.
terminalcurl -X POST https://api.kontier.eu/v1/subscriptions \ -H "Idempotency-Key: e51f7b93" \ -d '{"customer_id":"cus_8f2k","plan_id":"plan_pro", "billing_interval_unit":"MONTH","currency":"EUR"}'→ 201 · subscription.activated · pinned
- 05
invoice.createdUsage senden, Rechnung entsteht
quantity ist ein String - Dezimalstellen überleben den Transport. Der idempotency_key im Body dedupliziert das Event selbst.
terminalcurl -X POST https://api.kontier.eu/v1/usage-events \ -H "Idempotency-Key: evt_9a2f" \ -d '{"subscription_id":"sub_44c1","metric_key":"api_calls", "quantity":"18402","idempotency_key":"evt_9a2f"}'→ 202 · queued → invoice.created · 412,80 €
Was die API garantiert.
Zusagen statt Feature-Liste - das hält jede Antwort, jeder Fehler und jeder Webhook verbindlich ein.
Signiert, at-least-once, replay-fähig.
HMAC-SHA256 über den rohen Body, Secret mit whsec_-Präfix. Sechs Zustellversuche (1m, 5m, 30m, 2h, 12h), Dedup über die Envelope-ID. Ohne Signing-Secret wird nicht zugestellt - fail closed.
RFC 9457 Problem Details.
Jeder Fehler ist maschinenlesbar: type, title, status, detail, code - plus request_id für den Support. Kein Raten, kein Regex auf Fehlertexte.
Pflicht, nicht Option.
Idempotency-Key ist auf jedem POST erforderlich. Der Key ist an den SHA-256 des Bodys gebunden: derselbe Key mit anderem Body ergibt 409. 5xx werden nie gecacht, ein Retry führt also wirklich aus.
Cursor statt Offset.
Keyset über (created_at, id), Cursor als opakes Token. Stabil bei parallelen Inserts - has_more ist das verbindliche Signal, nicht total_count.
Fail closed, wo es zählt.
Fällt der Idempotenz-Speicher aus, antworten geldbewegende Routen (/charge, /refund, /capture, /finalize) mit 503 statt ohne Dedup zu laufen. Lieber ein Retry als eine Doppelbuchung.
Die Plan-Version ist gepinnt.
Subscriptions halten eine ganzzahlige plan_version. Katalogänderungen verändern niemals laufende Rechnungen; ein Wechsel ist ein expliziter Aufruf, kein Nebeneffekt.
Die Spezifikation ist der Vertrag.
OpenAPI 3.1, direkt aus dem Code generiert - nicht nebenher gepflegt. 324 Pfade, 453 Operationen, 859 Schemas und 114 dokumentierte Webhook-Events. Client-Generierung inklusive.
Die Rechnung, die die Prüfung besteht.
XRechnung und ZUGFeRD entstehen aus derselben Rechnung, die Sie ohnehin erzeugen. Kein zweiter Datenpfad, kein Export nach Excel, keine Bibliothek, die Sie selbst gegen die KoSIT-Regeln halten müssen.
Vom Aufruf zum gültigen XML
Dokument erzeugen - Profil wählen, Rechnung referenzieren.
POST /v1/e-invoicing/documents{ "invoice_id": "inv_7c21", "profile": "XRECHNUNG_3_0_UBL", "jurisdiction": "DE" }
Rohes XML abholen - das, was beim Empfänger ankommt.
GET /v1/e-invoicing/documents/{id}/raw→ 200 · application/xml
Befunde lesen - jede verletzte Regel mit ID, nicht "ungültig".
GET /v1/e-invoicing/documents/{id}/findings→ [ { "rule": "BR-DE-15", … } ]
Was validiert wird
Eigene Regel-Engine
EN 16931, KoSIT BR-DE und PEPPOL BIS laufen als Regelwerk im Dienst - kein externer Schematron-Service, der ausfallen kann.
Leitweg-ID, echt geprüft
BR-DE-1 verlangt die BuyerReference (BT-10). BR-DE-15 prüft ihre Form - genau dieses Muster:
^[0-9A-Z]{2,12}(-[0-9A-Z]{0,30})?-[0-9]{2}$ Quarantäne statt stiller Fehler
Befunde werden pro Dokument gespeichert. Ein Dokument, das die Regeln verletzt, geht in Quarantäne, statt unbemerkt an eine Behörde zu gehen.
17 Profile im Katalog
- XRECHNUNG_3_0_UBL
- XRECHNUNG_3_0_CII
- EN16931_UBL_2_1
- EN16931_CII_D16B
- PEPPOL_BIS_BILLING_3_UBL
- ZUGFERD_2_COMFORT
- FACTURX_EN16931
- ZUGFERD_2_XRECHNUNG
- +9
Hybride PDF/A-3-Profile (Factur-X, ZUGFeRD) brauchen den Mustang-Dienst; reine XML-Profile laufen ohne ihn.
Artefakte werden mit Bytes und Hash-Kette archiviert - die GoBD-Frage "ist das noch dieselbe Rechnung" ist beantwortbar.
Der Rest steht in der Referenz.
Vollständige Endpunkte, Schemas, Webhook-Kataloge und Beispiele - ohne Anmeldung lesbar, mit Sandbox-Keys sofort ausprobierbar. Und überall auf der Website zeigt die Taste i zu jedem Artefakt den API-Pfad - auch hier.
Erst die API prüfen, dann entscheiden?
Wir schreiben, wenn sich an der API etwas ändert: neue Endpunkte, neue SDKs, angekündigte Breaking Changes.
Fast geschafft - bitte E‑Mail bestätigen.
Wir haben Ihnen eine Bestätigungsmail geschickt. Erst mit dem Klick auf den Link darin sind Sie eingetragen. Nichts erhalten? Sehen Sie im Spam-Ordner nach.