Zum Hauptinhalt springen
DokumentOffene API-PlattformAuthentifizierung und Ratenbegrenzung

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)

bash
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

bash
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)

text
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>
Verwenden Sie Abfrageparameter mit Vorsicht

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

  1. Authorization: Bearer dyk_…
  2. X-API-Key: dyk_…
  3. ?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

Paketpro Minutetäglich
Free602,000
Pro30050,000
Team1,200500,000
Enterprise6,000Alle

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
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-Window Zeigt Ihnen an, welches Fenster erreicht wurde (Minute/Tag)
  • Exponentieller Backoff + Jitter; Versuchen Sie es nicht sofort erneut, nachdem Sie 429 erhalten haben
Mehrere Schlüssel zur Aufteilung des Datenverkehrs

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

StatuscodeBedeutungBewältigungsstrategien
200Erfolg
202Akzeptiert (wenn die Ausführung gestartet wird)Fragen Sie den Status mit der zurückgegebenen Ausführungs-ID ab
400Ungültiger Anfragetext (JSON-/Feldfehler)Anfrage beheben; Versuchen Sie es nicht erneut
401Token fehlt/falsches Format/widerrufen/abgelaufen/unzureichender GültigkeitsbereichÜberprüfen Sie Token und Umfang erneut. Versuchen Sie es nicht noch einmal
403Das Konto des Token-Inhabers wurde deaktiviert/gesperrtWenden Sie sich an Ihren Kontoadministrator. Versuchen Sie es nicht noch einmal
404Die Ressource existiert nicht oder ist nicht sichtbarID/Bereich prüfen; Versuchen Sie es nicht noch einmal
409Statuskonflikt (z. B. Genehmigung wurde entschieden)Fragen Sie den aktuellen Status erneut ab
429RatenbegrenzungVersuchen Sie es erneut, nachdem Sie „Retry-After“ befolgt haben
500/502/503ServerfehlerExponentieller Backoff + Jitter, 3–5 Mal wiederholen
Warum 401 nicht zwischen Gründen unterscheidet

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.