Überprüfung und typische Probleme - REST API

Ein kontrolliertes Testereignis

curl -X POST https://dockray.io/api/v1/PROJECT_TOKEN/project \
  -H 'Authorization: Bearer PROJECT_PRIVATE_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"exception":{"values":[{"type":"RuntimeException","value":"DockRay-Kontrollmeldung"}]}}'

Eine Antwort 200 {"success": true} bedeutet, dass das Ereignis gespeichert wurde. Prüfe das Panel unter Fehler des Projekts, auf das der Token zeigt.

Typische Probleme

401 statt eines gespeicherten Ereignisses

An keiner der drei Stellen - URL, Formularfeld oder Authorization-Header - war ein Schlüssel vorhanden. Das ist die einzige Ursache für einen 401; der Code sagt nichts darüber aus, ob der Schlüssel gültig gewesen wäre.

404 trotz scheinbar korrekter Adresse

Ein Schlüssel ist vorhanden, passt aber nicht zum Projekt aus der URL: er wurde widerrufen, gehört zu einem anderen Projekt, oder das Projekt ist im Panel deaktiviert. Die Antwort ist identisch, wenn der Token in der URL überhaupt nicht existiert - das ist beabsichtigt, damit nicht verraten wird, welche Projekte tatsächlich in der Datenbank stehen.

200 {"success": false} für einen Erfolg gehalten

Diese Antwort hat zwei unabhängige Ursachen: das monatliche Fehlerkontingent ist aufgebraucht (siehe unten), oder dem Body fehlt ein Pflichtfeld - exception.values[0].type und .value bei einem Fehler, ein nicht leeres contexts.trace.data bei einer Transaktion. Prüfe die Form des Payloads, bevor du das Kontingent verdächtigst.

Ein gzip-komprimierter Body verliert den Schlüssel

Sendest du einen Body mit dem Header Content-Encoding: gzip, wird ein Formularfeld mit dem Schlüssel darin nie gelesen - der Parser liest den komprimierten Stream direkt als JSON, ohne ihn auf der Suche nach Formularfeldern zu dekomprimieren. Verschiebe den Schlüssel in die URL oder in den Authorization-Header.

Eine Transaktion kommt mit {"success": false} zurück

Meist fehlt contexts.trace.data oder ist leer - es ist das einzige Pflichtfeld einer Transaktionsmeldung.

Ein Fehler zerfällt in viele Einträge

Der Fingerabdruck wird aus type und value berechnet. Eine in den Meldungstext eingesetzte Datensatzkennung zerlegt einen Fehler in tausend Zeilen - verschiebe sie stattdessen in den Anfragekontext oder den Stacktrace.

Anfragen enden mit einem 429

Das ist das Anfragelimit pro Minute und Projekt-Token (standardmäßig 1200), unabhängig vom monatlichen Fehlerkontingent - meist bedeutet es einen sich verschleifenden Client oder Wiederholungsversuche ohne Wartezeit.

Das Panel antwortet 200, aber es gibt kein Ereignis

Eine Antwort 200 {"success": false} bedeutet, dass das Konto sein monatliches Fehlerkontingent aufgebraucht hat. Die Integration behandelt das nicht als Störung - zu Recht. Das Kontingent siehst du im Konto-Dashboard; bis zum Monatsende wird es aus der erfassten Nutzung berechnet, Fehler zu löschen setzt es also nicht zurück.

Es funktioniert weiterhin nicht

Arbeite die Checkliste zur Fehlerbehebung durch, und wenn das nicht hilft, schreib uns. Nenne den Projektnamen, die Version der Integration und ungefähr die Uhrzeit des Tests: das verkürzt den Weg zur Antwort.