Prüfschritte
Vor der Integration
- API-Key nicht im Frontend einbauen.
- Uploadgrößen und Tariflimits prüfen.
- Timeouts und Wiederholungen bewusst setzen.
- Keine echten Rechnungen in Entwicklungslogs 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.
- Prüfebene und Grenzen immer mit exportieren.
Beispielhafte Einordnung
| Fall | Was geprüft wird | Was daraus folgt |
|---|---|---|
| POST /api/invoices | Datei hochladen | multipart/form-data |
| GET /api/invoices/{id} | Status und Basisdaten lesen | JSON |
| GET /api/invoices/{id}/report | Prüfbericht abrufen | |
| GET /api/invoices/{id}/export.csv | Tabellenexport | CSV |
Warum API und Bericht zusammengehören
Eine API liefert strukturierte Daten. Ein Bericht erklärt denselben Vorgang für Menschen. Beide sollten auf dieselbe Datei, denselben Status und dieselbe Prüfebene verweisen.
Keine stillen Garantien
Ein JSON-Feld wie validation_status darf nicht suggerieren, dass eine vollständige Normprüfung lief, wenn nur Basisdaten erkannt wurden.
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.