# Limits (https://developer.bimetrics.de/limits)

Anfragen pro Minute, Upload-Grenzen und Größen von Anfragen.

| Grenze | Wert |
| --- | --- |
| Anfragen je Schlüssel | 60 pro Minute |
| Anfragen je Firma, alle Schlüssel zusammen | 120 pro Minute |
| Uploads je Firma | 10 pro Minute |
| Gleichzeitige Uploads je Firma | höchstens 2 |
| Größe einer Datei beim Upload | 30 MiB |
| Größe einer Upload-Anfrage (gesamt) | 31 MiB |
| Größe einer JSON-Anfrage | 1 MiB |
| Treffer je Seite (`limit`) | höchstens 1.000 |
| Startposition (`offset`) | höchstens 1.000.000 |
| Anfragen mit ungültigem Schlüssel je Client | 120 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](https://bimetrics.de/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.
* **Uploads:** Uploads zählen zu den Anfragen und haben ein eigenes Budget je Firma. Außerdem laufen nur wenige Uploads einer Firma gleichzeitig.
* **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](/filtern).

## Wenn eine Grenze erreicht ist

Die API antwortet mit `429` und dem Code `APIRateLimit`. Der Header `Retry-After` nennt die Wartezeit in Sekunden. Warte diese Zeit ab und wiederhole die Anfrage dann; Uploads mit derselben `X-Upload-Request-Id`.

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.
