Unser größter Kunde sind wir selbst
Heute launchen wir invoice.xhub.io – eine SaaS-Anwendung zum Erstellen und Versenden von E-Rechnungen, komplett ohne Code. Was von außen wie ein neues Produkt aussieht, ist unter der Haube ein ziemlich radikaler Proof of Concept: invoice.xhub.io ist auf der invoice-api.xhub.io Engine gebaut.
Nicht daneben. Nicht inspiriert davon. Sondern direkt darauf.
Warum Dogfooding mehr ist als ein Buzzword
Jeder API-Anbieter sagt: "Unsere API ist production-ready." Aber der ehrlichste Beweis ist, wenn man sein eigenes Produkt darauf baut. Genau das haben wir gemacht.
Jede E-Rechnung, die ein Nutzer in invoice.xhub.io erstellt, durchläuft exakt denselben Weg wie ein API-Call eines Entwicklers:
- Strukturierte Daten werden aus dem Formular oder dem AI-Assistenten gesammelt
- Dieselbe Erzeugungs-Engine wandelt sie in XRechnung, ZUGFeRD oder Peppol BIS um
- Dieselbe Validierung prüft gegen KoSIT-Schemas und Schematron-Regeln
- Dieselbe PDF-Engine erzeugt PDF/A-3 mit eingebettetem XML
Kein Sonderweg. Kein internes Shortcut. Wenn die Engine einen Bug hat, merken wir es zuerst – weil es unser eigenes Produkt betrifft.
Wo die API überall steckt
Konkret nutzt invoice.xhub.io die Invoice-API Engine an diesen Stellen:
Rechnungserzeugung
Wenn ein Nutzer im SaaS auf "Rechnung erstellen" klickt, passiert im Hintergrund dasselbe wie bei einem POST /api/v1/invoice/de/xrechnung/generate Call. Die Eingabedaten werden in das interne Invoice-Modell übersetzt, die Engine erzeugt das XML – und der Nutzer bekommt seine XRechnung, ohne zu wissen, was XRechnung überhaupt technisch ist.
Validierung in Echtzeit
Der SaaS validiert Rechnungen während der Eingabe. Fehlt die USt-ID? Die Validierungs-Engine meldet BR-DE-03. Aber statt dem kryptischen Fehlercode zeigt das UI: "Bitte trage die USt-IdNr. deines Kunden ein." Gleiche Prüfung, andere Sprache.
PDF-Generierung
ZUGFeRD verlangt ein PDF/A-3 mit eingebettetem XML. Die PDF-Engine, die API-Kunden über den Endpoint nutzen, erzeugt auch die PDFs im SaaS. Gleiche Schriften, gleiches Layout, gleiche Konformität.
Parsing eingehender Rechnungen
Nutzer können im SaaS auch E-Rechnungen hochladen und prüfen lassen. Die Parsing-Engine extrahiert strukturierte Daten aus XRechnung-XML oder ZUGFeRD-PDFs – dieselbe, die auch den Parser-Endpoint der API antreibt.
Die Architektur dahinter: Shared Libraries
Der Grund, warum das funktioniert, ist eine Entscheidung, die wir von Tag 1 getroffen haben: Die gesamte Kernlogik lebt in eigenständigen Bibliotheken, nicht in der API selbst.
| Bibliothek | Aufgabe | Genutzt von |
|---|---|---|
| Invoice Outbound DE | XRechnung, ZUGFeRD, Peppol erzeugen | API + SaaS |
| Invoice Inbound DE | E-Rechnungen parsen und validieren | API + SaaS |
| Invoice Interface | Gemeinsames Datenmodell | API + SaaS |
| PDF Engine | PDF/A-3 mit eingebettetem XML | API + SaaS |
Wenn wir einen Bug in der Validierung fixen, ist er in beiden Produkten gleichzeitig behoben. Wenn wir ein neues Format unterstützen, steht es in beiden Produkten zur Verfügung. Kein Sync-Problem, kein Feature-Drift.
Was wir durch Dogfooding gefunden haben
Unser eigenes Produkt auf der API zu bauen hat Probleme aufgedeckt, die kein Unit-Test gefunden hätte:
Edge Cases bei der Validierung
Ein Nutzer im SaaS gibt Rechnungsdaten Stück für Stück ein. Das bedeutet: Die Engine muss auch mit unvollständigen Daten sinnvolle Fehlermeldungen liefern – nicht nur mit fertigen Rechnungen. Das hat uns gezwungen, die Validierung granularer zu machen.
Performance unter realen Bedingungen
Im API-Kontext ist ein einzelner Request schnell. Aber im SaaS validieren wir bei jedem Tastendruck. Das hat uns gezeigt, wo die Engine optimiert werden muss – und diese Optimierungen kommen jetzt auch API-Kunden zugute.
Fehlermeldungen für Menschen
BR-CO-10: Sum of line amounts does not equal invoice total ist für einen Entwickler klar. Für einen Freelancer nicht. Wir haben eine Übersetzungsschicht gebaut, die Schematron-Fehlercodes in natürliche Sprache übersetzt. Dieses Mapping könnten wir in Zukunft auch als API-Feature anbieten.
Was das für API-Kunden bedeutet
Wenn du die Invoice-API nutzt, profitierst du direkt davon, dass wir sie selbst einsetzen:
- Höhere Stabilität – Bugs fallen bei uns intern auf, bevor sie dich treffen
- Bessere Performance – Optimierungen, die wir für den SaaS brauchen, landen in der Engine
- Realistischere Tests – Unsere Testabdeckung geht über synthetische Testdaten hinaus
- Schnellere Iteration – Feature-Requests aus dem SaaS-Team fließen direkt zurück
Die API ist kein Nebenprodukt. Sie ist das Fundament.
Zwei Produkte, eine Engine
| invoice-api.xhub.io | invoice.xhub.io | |
|---|---|---|
| Für wen | Entwickler & Tech-Teams | Freelancer, KMUs, Buchhaltung |
| Zugang | REST-API mit API-Key | Web-Oberfläche im Browser |
| Engine | Direkt | Dieselbe – über Shared Libraries |
| Validierung | KoSIT-Schematron | KoSIT-Schematron (+ menschliche Fehlermeldungen) |
| Output | XML, PDF, JSON | Dieselben Formate, fertig zum Download/Versand |
Ausprobieren
Du bist Entwickler? Die API bleibt wie gehabt unter invoice-api.xhub.io. Teste sie im Playground oder starte mit dem Quickstart.
Du willst einfach eine E-Rechnung erstellen? invoice.xhub.io – selbe Engine, kein Code nötig.
Fragen? Kontaktiere uns.