Authentifizierung und Ratenbegrenzung
Drei Schreibmethoden für Bearer / X-API-Key / Abfrage, Paketratenbegrenzung, HTTP-Statuscode-Semantik.
Alle Endpunkte der offenen Plattform werden einheitlich über den API-Schlüssel authentifiziert. Auf dieser Seite werden die drei Möglichkeiten zum Schreiben von Token, Paketratenbeschränkungen und die Semantik von Fehlerantworten klar erläutert.
Drei Methoden zum Schreiben der Authentifizierung
1. Autorisierung: Inhaber (empfohlen)
curl https://braidrun.com/api/v1/workflows \
-H "Authorization: Bearer dyk_<id>_<secret>"Die standardmäßigste Schreibmethode, die standardmäßig von allen SDKs unterstützt wird. Produktionsumgebung wird bevorzugt.
2.X-API-Key-Header
curl https://braidrun.com/api/v1/workflows \
-H "X-API-Key: dyk_<id>_<secret>"Geeignet für Szenarien, in denen der Proxy einiger geschlossener Netzwerke den Autorisierungsheader nicht weiterleiten kann. Funktional gleichbedeutend mit Bearer.
3. Abfrageparameter ?api_key= (nur in Szenarien, in denen Header nicht geschrieben werden kann)
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>Abfrageparameter werden im Browserverlauf, im Referrer-Header, in HTTP-Serverzugriffsprotokollen und in CDN-Protokollen aufgezeichnet. Es wird nur in Szenarien verwendet, die in Form von GET-Links ausgelöst werden müssen (z. B. Ein-Klick-Genehmigungslinks für E-Mail/Slack/Telegram) und wird mit einem kurzen TTL-Schlüssel verwendet. Geben Sie niemals die Bearer-Priorität auf, um Parameter abzufragen.
Priorität
Authorization: Bearer dyk_…X-API-Key: dyk_…?api_key=dyk_…
Versuchen Sie es von oben nach unten und beenden Sie die Analyse, wenn Sie eine nicht leere finden.
Ratenbegrenzung
Für jeden API-Schlüssel gibt es zwei Obergrenzen: „pro Minute“ und „täglich“, die automatisch entsprechend dem Paket des Schlüsseleigentümers angewendet werden. Jeder Schlüssel verfügt über ein unabhängiges Kontingent und wird nicht mit anderen Schlüsseln im selben Konto geteilt.
Paketvergleichstabelle
| Paket | pro Minute | täglich |
|---|---|---|
| Free | 60 | 2,000 |
| Pro | 300 | 50,000 |
| Team | 1,200 | 500,000 |
| Enterprise | 6,000 | Alle |
Fenstersemantik
- Minutenfenster · Verwenden Sie Epochenminuten als Schlüssel, und die Grenze wird jede Minute automatisch zurückgesetzt (nicht das Schiebefenster ab dem ersten Aufruf).
- täglich (Tagesfenster) · Verwenden Sie das UTC-Datum als Schlüssel, das jeden Tag automatisch um 00:00 UTC zurückgesetzt wird
Wenn das Limit erreicht ist
HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 60
X-RateLimit-Window: minute
Content-Type: application/json
{
"error": "Rate limit exceeded",
"window": "minute",
"limit": 60,
"retryAfterSeconds": 38
}Der Kunde sollte:
- Lesen Sie den Retry-After-Header (Anzahl der Sekunden), warten Sie die entsprechende Zeitspanne und versuchen Sie es dann erneut
X-RateLimit-WindowZeigt Ihnen an, welches Fenster erreicht wurde (Minute/Tag)- Exponentieller Backoff + Jitter; Versuchen Sie es nicht sofort erneut, nachdem Sie 429 erhalten haben
Benötigen Sie einen höheren Durchsatz? Für unterschiedliche Umgebungen/unterschiedliche Integrationen werden unabhängige Schlüssel ausgegeben, und jeder Schlüssel erhält ein volles Kontingent. Ein Pro-Benutzer, der 3 Schlüssel öffnet, entspricht einer Gesamtkapazität von 900 U/min. Dies ist auch die bewährte Methode zur Unfallortung – wenn ein Problem auftritt, müssen Sie nur nachsehen, welcher Schlüssel eine ungewöhnliche Nutzung aufweist.
Http-antwortcode
| Statuscode | Bedeutung | Bewältigungsstrategien |
|---|---|---|
200 | Erfolg | — |
202 | Akzeptiert (wenn die Ausführung gestartet wird) | Fragen Sie den Status mit der zurückgegebenen Ausführungs-ID ab |
400 | Ungültiger Anfragetext (JSON-/Feldfehler) | Anfrage beheben; Versuchen Sie es nicht erneut |
401 | Token fehlt/falsches Format/widerrufen/abgelaufen/unzureichender Gültigkeitsbereich | Überprüfen Sie Token und Umfang erneut. Versuchen Sie es nicht noch einmal |
403 | Das Konto des Token-Inhabers wurde deaktiviert/gesperrt | Wenden Sie sich an Ihren Kontoadministrator. Versuchen Sie es nicht noch einmal |
404 | Die Ressource existiert nicht oder ist nicht sichtbar | ID/Bereich prüfen; Versuchen Sie es nicht noch einmal |
409 | Statuskonflikt (z. B. Genehmigung wurde entschieden) | Fragen Sie den aktuellen Status erneut ab |
429 | Ratenbegrenzung | Versuchen Sie es erneut, nachdem Sie „Retry-After“ befolgt haben |
500/502/503 | Serverfehler | Exponentieller Backoff + Jitter, 3–5 Mal wiederholen |
Fehlendes, abgelaufenes, widerrufenes Token und unzureichender Bereich geben alle einheitlich 401 zurück, ohne den spezifischen Fehlergrund preiszugeben. Dadurch wird verhindert, dass Angreifer Versuch und Irrtum verwenden, um herauszufinden, welche Schlüssel vorhanden sind/welche Bereiche aktiviert sind. Der vollständige Fehlergrund (Feld „Grund“) wird im Audit-Protokoll gespeichert und kann vom Administrator überprüft werden.