Skip to main content
API-Fehler von LogBrew verwenden einen einheitlichen JSON-Umschlag. Steuern Sie Ihr Programm mit code und next_action. Zeigen Sie error und next als reinen Text an. Werten Sie den Wortlaut von error oder next nicht aus.
Manche Antworten enthalten zusätzliche Felder, zum Beispiel limit, reset_at oder retry_after_seconds. Die Tabelle Fehlercodes nennt sie.

Fehlerantwort behandeln

  1. Lesen Sie den HTTP-Status.
  2. Prüfen Sie, ob der Body JSON ist, bevor Sie code lesen.
  3. Wählen Sie den Zweig im Client anhand von Status und code zusammen.
  4. Zeigen Sie error und next als reinen Text an. Rendern Sie sie nicht als HTML, und führen Sie sie nicht als Befehle aus.
  5. Verwenden Sie next_action für die automatische Wiederherstellung. Kennt der Client die Aktion nicht, halten Sie an und zeigen den Fehler an.
  6. Bewahren Sie die gelieferten Werte von limit, reset_at und retry_after_seconds zusammen mit der fehlgeschlagenen Anfrage auf.
  7. Beachten Sie vor einer Wiederholung die Wiederholungsregeln.
Hat die Antwort keinen JSON-Umschlag, behalten Sie den HTTP-Status und vermerken den Code als nicht verfügbar. Erfinden Sie keinen LogBrew-code. Ein Proxy oder ein Netzwerkfehler kann dieses Ergebnis verursachen. Ersetzen Sie einen LogBrew-code nicht durch den Namen des HTTP-Status. Eine 400-Antwort kann zum Beispiel invalid_json oder invalid_path enthalten. Jeder Code braucht eine andere Korrektur. Halten Sie in Logs den HTTP-Status und den code fest. Schreiben Sie nicht den ganzen Body, Zugangsdaten oder Wiederherstellungs-Tokens in Logs.

Fehlercodes

Derselbe code kann bei mehr als einer Route vorkommen. Der Text von next und die Werte von next_action können je nach Route unterschiedlich sein. Verwenden Sie die gelieferten Werte. Ein Endpunkt liefert nur die Codes, die zu seiner Authentifizierung, Methode, seinem Body und seinen Limits passen. Eine unbekannte ID und eine ID, auf die Sie keinen Zugriff haben, können dieselbe Antwort liefern. Ermitteln Sie über den Fehlertext nicht, welchem Konto eine ID gehört. Ein unbekannter API-Pfad liefert 404 mit not_found.

Limit-Felder

Das aktuelle Kontingent und die Nutzung lesen Sie über die Konto-API.

Wiederholungsregeln

Entscheiden Sie anhand von Code und Operation über eine Wiederholung. Der Status allein reicht nicht aus.
  • Starten Sie für eine fehlgeschlagene Anfrage keine parallelen Wiederholungen.
  • Bei rate_limited enthält die Antwort außerdem die Header Retry-After und X-RateLimit-After. Beide enthalten dieselbe Anzahl Sekunden wie retry_after_seconds.
  • Eine Zeitüberschreitung beweist nicht, dass das Ergebnis leer ist.
Ein Ratenlimit begrenzt, wie oft Sie Anfragen senden. Ein Nutzungslimit begrenzt das Kontingent des Kontos für einen Abrechnungszeitraum. Beide verwenden 429. Halten Sie ihre Felder auseinander. Zeigen Sie während eines der beiden Limits an, dass die Erfassung oder eine Abfrage verzögert ist. Zeigen Sie alte Daten nicht als Ergebnis einer neuen Abfrage an.

Schreibvorgänge

Eine Zeitüberschreitung, eine 5xx-Antwort oder ein Netzwerkfehler beweist nicht, dass ein Schreibvorgang fehlgeschlagen ist. Bevor Sie einen Schreibvorgang erneut senden:
  1. Unterstützt die Route einen Idempotenzschlüssel, senden Sie denselben Schlüssel und denselben Body erneut. Verwenden Sie einen neuen Schlüssel nur für einen neuen Vorgang.
  2. Hat die Route keinen Idempotenzschlüssel, lesen Sie zuerst die Ressource. Senden Sie den Schreibvorgang nur erneut, wenn die Änderung fehlt.
  3. Finden Sie das Ergebnis nicht, beenden Sie automatische Wiederholungen, und informieren Sie den Nutzer.
Diese Routen akzeptieren einen Wiederholungsschlüssel: Ein Wert für Idempotency-Key hat 1 bis 128 sichtbare ASCII-Zeichen. Andere Werte liefern 422 mit validation_failed. idempotency_conflict bedeutet, dass der Schlüssel zu einer anderen Anfrage gehört. Ändern Sie nicht den Body einer Wiederholung, die den ursprünglichen Schlüssel verwendet.

Fehler in der Struktur der Anfrage

invalid_json bedeutet, dass der Server den Body nicht als JSON-Struktur der Route annehmen kann. Prüfen Sie Content-Type, Größe des Bodys, JSON-Syntax, Pflichtfelder und Feldtypen. Der HTTP-Status zeigt, welcher Teil fehlgeschlagen ist: validation_failed mit dem Fehler invalid query parameters bedeutet, dass der Server den Query-String nicht lesen kann. Prüfen Sie die Parameternamen und die Typen der Werte. Senden Sie keine unbekannten Query-Parameter. Die Referenz der Abfragefilter listet die Parameter für jede Route auf. invalid_path mit dem Status 400 bedeutet, dass ein Pfadwert, zum Beispiel eine Projekt-ID, das falsche Format hat. Verschieben Sie einen Pfadwert nicht in einen Query-Parameter. Eine 500-Antwort mit invalid_path oder invalid_multipart beweist nicht, dass die Anfrage falsch war. Beachten Sie die Wiederholungsregeln.

Fehler bei Authentifizierung und Zugriff

  • unauthorized bedeutet, dass die Konto-Authentifizierung fehlt, ungültig oder abgelaufen ist. Senden Sie Authorization: Bearer <token>, oder melden Sie sich erneut an. Manche Routen liefern next_action.code authorize_request mit einem routenspezifischen next, zum Beispiel bei einer Verbindung zum Live-Feed ohne gültiges Ticket.
  • ingest_key_invalid gilt nur für die Signalaufnahme. Konfigurieren Sie einen aktuellen Schlüssel für genau dieses Projekt.
  • forbidden bedeutet, dass das Konto die Aktion nicht ausführen darf. Wiederholen Sie nicht mit anderen Ressourcen-IDs.
  • not_found bedeutet, dass die Ressource für das Konto nicht verfügbar ist.
Verwenden Sie keinen Ingest-Schlüssel anstelle eines Konto-Bearer-Tokens. Verwenden Sie kein Konto-Bearer-Token anstelle eines Ingest-Schlüssels.

Fehlerdetails sicher halten

  • Eine Antwort mit account_recovery_available enthält ein kurzlebiges recovery_token. Bewahren Sie es in einem geschützten Zustand des Clients auf. Schreiben Sie es nicht in Logs, URLs, Screenshots, Support-Meldungen oder Prompts für Agenten.
  • Die 500-Codes verwenden immer die Nachricht Internal error. Die Antwort nennt nicht die Komponente, die fehlgeschlagen ist. Raten Sie die Ursache nicht.
  • Fügen Sie einem angezeigten Fehler keine Zugangsdaten, privaten Diagnosedaten oder Kundendaten hinzu.
  • Eine API-Antwort erlaubt keinen Kauf, keine Löschung und keine andere Kontoänderung. Holen Sie vor solchen Aktionen die Zustimmung des Nutzers ein.

Beispiele

Diese Beispiele zeigen die Struktur des Umschlags. Der Text von error und next kann sich je nach Route unterscheiden.

Validierungsfehler

Ungültige Query-Parameter

Ungültiges JSON

Ungültiger Pfadwert

Ungültiger Multipart-Upload

Ungültiges WebSocket-Upgrade

Authentifizierung fehlgeschlagen

Ungültiger Ingest-Schlüssel

Diese Antwort gilt für die Signalaufnahme, nicht für Abfragen des Kontos. Der Schlüssel muss zum Projekt in der Anfrage gehören.

Ressource nicht gefunden

Zugriff verweigert

Nicht unterstützte Methode

Zeitüberschreitung der Anfrage

Idempotenzkonflikt

Ratenlimit

Nutzungslimit

Der Text von next und der Wert von next_action hängen davon ab, ob ein Tarifwechsel möglich ist. Ist keiner möglich, ist next_action.code gleich wait_or_contact_support und das Ziel support.

Speicherlimit für Artefakte

Kontowiederherstellung verfügbar

Diese Antwort enthält zusätzlich deleted_at und ein kurzlebiges recovery_token. Bewahren Sie das Token in einem geschützten Zustand des Clients auf.

Kontowiederherstellung abgelaufen

Organisation pausiert

Serverfehler

storage_error, json_error und internal_error verwenden dieselbe error-Nachricht. Die Werte von code, next und next_action unterscheiden sich.
Endpunkte, Authentifizierung und Filter beschreibt die Telemetrie-API.