Verkraftet die API tausende Rechnungen im Monat?

Warum asynchron der entscheidende Punkt ist

Aus einer PDF die Rechnungsdaten zu lesen, sie zu prüfen und daraus eine gültige E-Rechnung zu bauen, dauert pro Beleg spürbar länger als ein Datenbankzugriff. Eine API, die darauf synchron wartet, bricht bei Stückzahlen zusammen oder zwingt Ihr System in lange offene Verbindungen.

Deshalb antwortet der Upload sofort mit einer conversion_id und einer status_url. Ihr System kann in einem Zug einliefern und die Ergebnisse später abholen. Ein Rechnungslauf blockiert damit nichts.

Die Zahlen

• 240 Requests pro Minute je Schlüssel. Jede Antwort trägt X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset, Sie müssen das Fenster also nicht raten.
• Listen mit bis zu 100 Einträgen pro Abruf, mit offset und Datumsfiltern. Ein Abgleich über einen ganzen Monat ist eine überschaubare Zahl von Aufrufen.
• Bis 15.000 Rechnungen im Monat im Enterprise-Tarif, bis 2.000 in Business. Der verbrauchte Anteil ist selbst über die API abfragbar, Sie sehen eine Grenze also kommen.

Was bei einer Störung passiert

Nichts geht verloren. Die Verarbeitung liegt in einer Warteschlange; eine Störung verzögert sie, sie verwirft nichts. Was nicht sauber konvertierbar ist, geht nicht still hinaus, sondern in die Freigabe, siehe Was passiert bei einer nicht konvertierbaren PDF.

Das ist bei hohen Stückzahlen wichtiger als eine Verfügbarkeitszahl: Bei einem Stapel von tausend Rechnungen zählt, dass am Ende jede einzelne verarbeitet und geprüft ist, nicht dass jede innerhalb einer Sekunde durch war. Was wir dazu zusagen, steht auf Sicherheit und Aufbewahrung.

Wenn der Stapel als eine große PDF kommt

Dann ist die API nicht der richtige Einstieg. Ein Sammel-PDF mit vielen Belegen wird zuerst aufgeteilt, siehe Sammel-PDF in Einzelrechnungen aufteilen.