Mit ERP — API-Integration

Onboarding in drei Schritten

1. 1 · Schlüssel & SandboxSie erhalten Test- und Produktionsschlüssel mit getrennten Berechtigungen (nur Ausstellen, nur Abholen, beides).
2. 2 · Feld-Mapping statt ProgrammierungIhr Exportformat (CSV, IDoc-artig, JSON) wird serverseitig auf das Rechnungsmodell gemappt — inklusive Positionszeilen. Ein Dry-Run zeigt das Ergebnis, bevor irgendetwas ausgestellt wird.
3. 3 · Testbeleg → Freigabe → produktivEin Sandbox-Beleg durchläuft die echte Validierung; passt alles, schalten Sie den Produktionsschlüssel frei. Der Integrationsstatus (Schlüssel, Mapping, erste Belege) ist jederzeit abrufbar.

Verlässlichkeit im Dauerbetrieb

• Idempotenz: dieselbe Belegnummer zweimal gesendet → ein Beleg, keine Dublette. Wiederholungen nach Timeouts sind gefahrlos.
• Ehrliche Fehler: ein invalider Beleg kommt als Fehler mit den konkreten Regelverstößen zurück — nie als stilles „wird schon passen“.
• Mandantentrennung & Segmente: ERP-Schlüssel funktionieren nur für ERP-Mandanten; Web-Konten haben keinen API-Zugriff und umgekehrt.
• Volles Archiv: auch API-Belege liegen 8 Jahre unveränderbar im GoBD-Archiv — Ihr ERP muss das nicht selbst können.

Sicherheit der Maschinenschnittstelle

API-Schlüssel werden gehasht gespeichert (Klartext nur einmal bei Erzeugung sichtbar), tragen Berechtigungen (nur Ausstellen, nur Abholen) und Umgebungen (Sandbox/Produktion) und lassen sich jederzeit rotieren. Jeder Aufruf ist dem Mandanten zugeordnet und protokolliert; Web-Oberfläche und Maschinen-API sind strikt getrennte Zugangswege.

Beispiel-Aufruf

POST /v1/erp/invoices · Authorization: Bearer <API-Key>
{"number":"RE-2026-1042","buyer":{"name":"Kunde GmbH","country":"DE","vat_id":"DE…"},"lines":[{"name":"Seefracht","net_price":2500,"service_type":"intl_transport"}]}
Antwort: {"status":"VALID","number":"RE-2026-1042", …} — oder die präzisen Validierungsfehler.

Häufige Fragen

So funktioniert die Anbindung technisch

Ihr System spricht eine schlanke REST-API mit API-Key-Authentisierung an: Es liefert die Rechnungsdaten als JSON (Kopf, Partner, Positionen, Steuer- und Zahlungsangaben), CoolHanX baut daraus die EN-16931-konforme XRechnung, prüft sie gegen BR-DE, vergibt die lückenlose Nummer, archiviert GoBD-konform und meldet den Status zurück. Die Ausstellung ist idempotent: Ein wiederholter Aufruf mit derselben Referenz erzeugt keine Doppelrechnung.

Vom ERP-Datensatz zur geprüften E-Rechnung

1. 1 · Mapping einrichtenIhre Feldnamen werden einmalig auf die EN-16931-BT gemappt — im Onboarding mit Testlauf (Sandbox), bevor produktiv gestellt wird.
2. 2 · Daten sendenIhr ERP ruft die API mit dem Rechnungsdatensatz auf.
3. 3 · Prüfen & ausstellenCoolHanX validiert, nummeriert, archiviert — oder gibt bei Fehlern konkrete BR-DE-Codes zurück, ohne eine Nummer zu verbrauchen.
4. 4 · Status zurückErgebnis (VALID/Fehler), Rechnungsnummer und Archiv-Referenz gehen an Ihr System zurück.

Onboarding, Sandbox und Preis

Für ERP-Kunden gibt es eine Sandbox zum gefahrlosen Testen des Mappings und der Ausstellung, bevor produktiv geschaltet wird. Das Angebot richtet sich nach Belegvolumen und Anbindungsaufwand — sprechen Sie uns an, wir erstellen ein passendes Angebot statt eines Pauschaltarifs.

Verwandte Themen

Welche ERP-Systeme und Formate wir anbinden

Angebunden wird alles, was Rechnungsdaten exportieren kann — die Formatarbeit übernimmt unser serverseitiges Mapping. Bewährte Wege:

In jeder Programmiersprache anbindbar

Die Schnittstelle ist eine schlanke REST-API mit API-Key — anbindbar aus Python, PHP, Java, C#, Node.js oder direkt per curl. Sie senden die Rechnungsdaten als JSON; CoolHanX baut, prüft, nummeriert, archiviert und meldet den Status zurück. Kein SDK-Zwang, keine proprietäre Bibliothek.

curl -X POST https://…/v1/erp/invoices -H 'Authorization: Bearer <API-Key>' -H 'Content-Type: application/json' -d '{…}'