Rate-Limits

Jeder API key verfügt über ein eigenes stündliches Anfragebudget. Ist es ausgeschöpft, antwortet die API mit 429 Too Many Requests, bis das rollierende Fenster zurückgesetzt wird.

Stündliches Budget pro Schlüssel

Das Standardbudget liegt bei 1000 Anfragen pro rollierender Stunde je API key. Jeder Schlüssel führt seinen eigenen Zähler — Schlüssel werden nicht gepoolt, und es gibt keine zusätzliche mandantenweite Obergrenze über dem Schlüssel-Limit.

Sind 1000/Stunde für Ihre Integration zu eng, bitten Sie den Betreiber, der den Schlüssel ausgestellt hat, das Limit zu erhöhen. Betreiber können das Limit beim Anlegen des Schlüssels festlegen. Um das Limit eines bestehenden Schlüssels zu ändern, widerruft der Betreiber den Schlüssel und stellt einen neuen mit dem gewünschten Limit aus. Gehen Sie nicht von 1000 als Standardwert aus — fragen Sie es beim Betreiber ab, wenn Sie genaues Pacing brauchen.

Was auf das Limit zählt

Jede authentifizierte Anfrage zählt, unabhängig vom Ausgang:

• 200 OK und 201 Created — gezählt
• 400, 403, 404, 429 — gezählt (die Anfrage hat das Schlüsselkontingent erreicht, bevor sie scheiterte)

Die einzige Ausnahme ist 401 Unauthorized — gescheiterte Authentifizierung zählt nicht, weil der Aufruf keinem konkreten Schlüssel zugeordnet werden kann.

Das Limit lässt sich also nicht durch fehlerhafte Anfragen umgehen. Validieren Sie Eingaben dort, wo es möglich ist, clientseitig.

429-Antwort

Überschreitet ein Schlüssel sein Budget, antwortet die API mit:

HTTP/1.1 429 Too Many Requests
Retry-After: 600
Content-Type: application/json

{ "detail": "Request was throttled. Expected available in 600 seconds." }

Die 600 oben ist nur ein Beispiel — der tatsächliche Wert variiert (zwischen 1 und etwa 3600), abhängig davon, wie viel des rollierenden Fensters noch übrig ist.

Der Retry-After-Header gibt die Anzahl Sekunden an, bis die nächste Anfrage erfolgreich sein sollte (kein HTTP-Datum). Warten Sie mindestens diese Zeit ab, bevor Sie erneut versuchen. Sofortige Wiederholungen oder enges Polling halten den Zähler nur dauerhaft am Anschlag.

Auditprotokoll

Jeder authentifizierte Aufruf wird in einem mandantenbezogenen Auditprotokoll festgehalten, unabhängig davon, ob er erfolgreich war oder mit einem 4xx endete. Jede Zeile erfasst:

• Mandant
• Welcher API key verwendet wurde
• HTTP-Methode und Anfragepfad
• Statuscode der Antwort
• Latenz in Millisekunden
• Zeitstempel

Das Protokoll erfasst keine Anfrage- oder Antwortkörper — es ist eine flache Betriebsspur, kein Archiv der übertragenen Inhalte.

Der Betreiber kann dieses Protokoll in der Admin-Konsole unter Einstellungen → API → Audit einsehen. Bei Verdacht auf einen kompromittierten Schlüssel oder zur Analyse des Verkehrsprofils einer Integration ist dies die verlässliche Quelle dafür, was tatsächlich an der API ankam.

Empfehlungen

Einige Muster halten die meisten Integrationen komfortabel unter dem Limit:

• Aggressiv zwischenspeichern. Stellplatz- und Kundenlisten ändern sich selten. Holen Sie sie einmal, halten Sie sie lokal vor und aktualisieren Sie nach Plan (z. B. einmal pro Stunde) statt bei jeder benutzergesteuerten Anfrage.
• Grössere Seiten anfordern. Verwenden Sie page_size=200 für Massenabrufe — eine Seite mit 200 Datensätzen kostet eine Anfrage, genau wie eine Seite mit 50.
• Serverseitig filtern. Nutzen Sie die Datumsbereichsfilter auf Buchungen, statt die volle Liste zu ziehen und clientseitig zu filtern.
• Bei 429 exponentiell zurückhalten. Halten Sie sich an Retry-After, verdoppeln Sie bei der nächsten Fehlanfrage die Wartezeit und so weiter. Eine sinnvolle Obergrenze (z. B. eine Stunde) hält die Integration höflich.
• Kein Polling. Wer nahezu in Echtzeit über Buchungen informiert sein möchte, fragt seinen Ansprechpartner bei CampOne nach Webhooks — sie stehen auf der Roadmap und werden Polling für Änderungs-Feeds ablösen.
• Pro Umgebung einen eigenen Schlüssel. Teilen Sie keinen Schlüssel zwischen Produktions- und Staging-Deployments — sonst lässt sich der Verkehr im Auditprotokoll nicht mehr zuordnen.