bimetricsEntwickler

Limits

Anfragen pro Minute, Tagesbudgets fürs Schreiben, Upload-Grenzen und Größen von Anfragen.

Als Markdown ansehen
GrenzeWert
Anfragen je Schlüssel60 pro Minute
Anfragen je Firma, alle Schlüssel zusammen120 pro Minute
Festschreiben und Vollstorno zusammen je Schlüssel10 pro Minute
Zuordnungsvorschläge je Schlüssel10 pro Minute
Schreibaufrufe je Firma2.000 pro Tag
Festschreiben und Vollstorno zusammen je Firma500 pro Tag
Neue Kontakte je Firma500 pro Tag
Uploads je Firma10 pro Minute
Gleichzeitige Uploads je Firmahöchstens 2
Größe einer Datei beim Upload30 MiB
Größe einer Upload-Anfrage (gesamt)31 MiB
Größe einer JSON-Anfrage1 MiB
Treffer je Seite (limit)höchstens 1.000
Startposition (offset)höchstens 1.000.000
Anfragen mit ungültigem Schlüssel je Client120 pro Minute
Wartezeit nach 429 (Retry-After)60 Sekunden

Die Werte sind die aktuellen technischen Schutzgrenzen. Anpassungen richten sich nach Ziffer 5.4, 8.2 und 10 der AGB.

So wirken die Grenzen

  • Anfragen: Die Zähler laufen je Minute. Jeder Schlüssel hat ein eigenes Budget; zusätzlich teilen sich alle Schlüssel einer Firma ein gemeinsames Budget.
  • Schreiben je Tag: Die Schreiboperationen zählen zusätzlich je Firma und Tag, über alle Schlüssel zusammen. Festschreiben und Vollstorno haben ein eigenes Tagesbudget, ebenso neue Kontakte. Der Tag endet um Mitternacht UTC.
  • Zuordnungsvorschläge: POST /api/match/suggestions vergleicht mit allen offenen Belegen und Umsätzen der Firma. Die Route hat ein eigenes Budget je Schlüssel und läuft je Firma nur einmal gleichzeitig.
  • Uploads: Uploads zählen zu den Anfragen und haben ein eigenes Budget je Firma. Außerdem laufen nur wenige Uploads einer Firma gleichzeitig.
  • Upload-Volumen: Je Firma und Tag speichert bimetrics Dateien mit zusammen höchstens 1 GiB, in den Tarifen Team und Scale 2 GiB. Es zählen alle Dateien, die an dem Tag in der Firma gespeichert werden, auch die Vorschauen, die bimetrics daraus erzeugt, und wieder gelöschte. Der Tag endet um Mitternacht UTC.
  • Offene Belege: Eine Firma kann höchstens 200 Belege gleichzeitig in der Verarbeitung haben, über API, App und MCP zusammen. Darüber nimmt der Upload keine weiteren an, bis die Verarbeitung aufgeholt hat; context.available nennt, wie viele gerade noch passen. Pausierte Belege (quota_paused) zählen nicht mit, ebenso Belege, deren Verarbeitung auf den nächsten Tag verschoben ist. Belege aus dem Mail-Postfach zählen mit, werden aber bewusst nie abgelehnt: Eine Mail lässt sich nicht nach Retry-After erneut zustellen.
  • Mails: Je Firma gehen höchstens 20 Empfänger am Tag raus, in der Testphase 3; Empfänger in Kopie zählen mit. Die Grenze gilt für App, API und MCP zusammen; darüber antwortet die API mit 429 DocumentMailLimitExceeded, send_document_mail lehnt mit demselben Code ab. Wie viele es heute schon waren, nennt sender.sentToday in POST /api/document-mail/preview. Der Tag endet um Mitternacht UTC.
  • Belege löschen und Sammelaktionen über MCP: Ab MCP-Version 2026-11-05 löscht delete_document höchstens 20 Belege je Firma am Tag, und ein Sammelaufruf nimmt höchstens 50 Belege. Der Tag endet um Mitternacht UTC.
  • Ungültige Schlüssel: Anfragen mit ungültigem, unbekanntem oder falsch gesendetem Schlüssel sind je Client (IP-Adresse) begrenzt. Das schützt vor dem Durchprobieren von Schlüsseln.
  • Größe: Anfragen über der erlaubten Größe lehnt die API mit 413 ab. Eine einzelne zu große Datei im Upload ergibt 400.
  • Filter: limit und offset haben Höchstwerte, siehe Filtern und Paginieren.

Wenn eine Grenze erreicht ist

Die API antwortet mit 429 und dem Code APIRateLimit, bei einem aufgebrauchten Tagesbudget mit WriteBudgetExceeded, beim Upload-Volumen mit UploadDailyLimit, bei zu vielen offenen Belegen mit DocumentQueueFull. Der Header Retry-After nennt die Wartezeit in Sekunden, bei Tagesbudget und Upload-Volumen die Zeit bis Mitternacht UTC. Warte diese Zeit ab und wiederhole die Anfrage dann; Uploads mit derselben X-Upload-Request-Id. Reicht ein Tagesbudget für deine Integration dauerhaft nicht, schreib an support@bimetrics.de.

Plane Abrufe so, dass sie gleichmäßig verteilt laufen, statt viele Anfragen auf einmal zu senden. Frage große Datenmengen seitenweise mit dem höchsten erlaubten limit ab.

Testphase

In der kostenlosen Testphase gelten zusätzlich Tagesgrenzen für faire Nutzung. Sie zählen je Firma, für API-Schlüssel und KI-Assistenten zusammen. Der Tag endet um Mitternacht UTC, in Deutschland also um 1:00 Uhr, im Sommer um 2:00 Uhr.

GrenzeWert
Abfragen je Firma1.000 pro Tag
Änderungen je Firma300 pro Tag
Festschreibversuche je Firma20 pro Tag
  • Abfragen: Routen mit Leserecht, auch Filter per POST, und MCP-Werkzeuge, die nichts ändern. Dateien über GET /api/blob zählen nicht mit.
  • Änderungen: die Schreiboperationen und die ändernden MCP-Werkzeuge. Uploads über die API zählen nicht mit, für sie gelten die Belege der Testphase. Uploads über einen Link von KI-Assistenten zählen mit.
  • Festschreibversuche: Rechnungen, Rechnungskorrekturen und Stornos. Anders als bei den Tagesbudgets oben zählen auch gescheiterte Versuche.
  • Belege: Die Testphase umfasst 100 Belege über alle Wege zusammen, siehe Beleg-Upload.
  • Serien: Ausstellende Serien richtest du in der App ein, siehe Schreiboperationen.
  • Gleichzeitige Aufrufe: Alle Firmen in der Testphase teilen sich 4 gleichzeitige Aufrufe von KI-Assistenten, bei den Werkzeugen mit eigenem Budget einen. Ist kein Platz frei, wartet ein Aufruf bis zu 3 Sekunden und endet dann mit „Too many parallel calls“. Er zählt trotzdem als Abfrage.

Ist eine Tagesgrenze erreicht, antwortet die API mit 429: bei Abfragen mit APIRateLimit, sonst mit WriteBudgetExceeded. Retry-After nennt die Zeit bis Mitternacht UTC, detail nennt den Grund in einem Satz. KI-Assistenten erhalten den Satz als Tool-Fehler.

Mit einem Tarif gelten ab der nächsten Anfrage die Grenzen oben; was am selben Tag schon verbraucht ist, zählt mit. Nach dem Ende der Testphase antwortet die API mit 403 APIUnavailable und einem Hinweis in detail, bis ein Tarif gewählt ist.

Auf dieser Seite