Prüfschritte
Vor der Integration
- API-Key serverseitig speichern.
- Uploadgrößen und Tariflimits prüfen.
- Timeouts und Wiederholungen festlegen.
- Keine Rechnungsinhalte in Entwicklungsprotokolle schreiben.
Fehler sauber behandeln
- 400 für unvollständige Anfrage.
- 401/403 für fehlende oder unzulässige Authentifizierung.
- 413 für zu große Dateien.
- 415 für nicht erlaubten Dateityp.
- 429 für Rate Limit.
Export einordnen
- JSON für Systeme, CSV für Tabellen, PDF für Menschen.
- Art der Prüfung und Grenzen immer mit exportieren.
Beispielhafte Einordnung
| Fall | Was geprüft wird | Was daraus folgt |
|---|---|---|
| POST /api/v1/rechnungen | Datei hochladen | multipart/form-data |
| GET /api/v1/rechnungen/{id} | Status, Rechnungsdaten, Positionen und Hinweise lesen | JSON mit readable_invoice |
| GET /api/v1/rechnungen/{id}/export.pdf | Prüfbericht abrufen | |
| GET /api/v1/rechnungen/{id}/export.csv | Tabellenexport mit Positionen | CSV |
API und Bericht
Eine API liefert strukturierte Daten. Ein Bericht erklärt denselben Vorgang für Menschen. Beide sollten auf dieselbe Datei, denselben Status und dieselbe Art der Prüfung verweisen.
Lesbare Daten im JSON
Die Detailantwort enthält readable_invoice mit Kopfbereich, Parteien, Positionen, Summen, Zahlungsdaten und Prüfhinweisen.
Häufige Fragen
Kann ich die API öffentlich im Browser nutzen?
Nein. API-Keys gehören serverseitig gespeichert.
Welche Exporte sind sinnvoll?
JSON für Systeme, CSV für Listen, PDF für Abstimmung und Nachweis.