Weryfikacja i typowe problemy - REST API

Kontrolowane zdarzenie testowe

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":"Kontrolny komunikat DockRay"}]}}'

Odpowiedź 200 {"success": true} znaczy, że zdarzenie zostało zapisane. Sprawdź panel w sekcji Błędy projektu wskazanego przez token.

Typowe problemy

401 zamiast zapisanego zdarzenia

Klucza nie było w żadnym z trzech miejsc: w adresie, w polu formularza ani w nagłówku Authorization. To jedyna przyczyna 401 - kod nie mówi nic o tym, czy klucz byłby poprawny.

404 mimo poprawnego adresu

Klucz jest w żądaniu, ale nie pasuje do projektu z adresu: klucz został odwołany, należy do innego projektu, albo projekt jest wyłączony w panelu. Odpowiedź jest identyczna, gdy token w adresie w ogóle nie istnieje - to celowe, żeby nie zdradzać, które projekty naprawdę są w bazie.

200 {"success": false} mylone z sukcesem

Ta odpowiedź ma dwa niezależne powody: wyczerpany miesięczny limit błędów (patrz niżej) albo brak wymaganych pól w ciele - exception.values[0].type i .value dla błędu, niepuste contexts.trace.data dla transakcji. Sprawdź kształt payloadu, zanim zaczniesz podejrzewać limit.

Ciało spakowane gzipem, a klucz zniknął

Gdy wysyłasz ciało z nagłówkiem Content-Encoding: gzip, pole formularza z kluczem wewnątrz tego ciała nigdy nie zostanie odczytane - parser czyta skompresowany strumień wprost jako JSON, nie rozpakowuje go w poszukiwaniu pól formularza. Przenieś klucz do adresu albo do nagłówka Authorization.

Transakcja wraca z {"success": false}

Najczęściej brakuje albo jest puste contexts.trace.data - to jedyne wymagane pole zgłoszenia transakcji.

Ten sam błąd rozbija się na wiele wpisów

Odcisk liczy się z type i value. Identyfikator rekordu wklejony w treść komunikatu rozbija jeden błąd na tysiąc wierszy - przenieś go do kontekstu żądania albo do stosu wywołań.

Żądania kończą się kodem 429

To limit żądań na minutę na token projektu (domyślnie 1200), niezależny od miesięcznego limitu błędów - zwykle znaczy to zapętlony klient albo ponawianie żądań bez odczekania.

Panel odpowiada 200, ale zdarzenia nie ma

Odpowiedź 200 {"success": false} znaczy, że konto wyczerpało miesięczny limit błędów. Integracja nie traktuje tego jak awarii - i słusznie. Limit widzisz na pulpicie konta; do końca miesiąca liczy się z zapisanego zużycia, więc nie zresetuje go usunięcie błędów.

Nadal nie działa

Przejdź przez listę kontrolną braku danych w panelu, a jeśli to nie pomoże - napisz do nas. Podaj nazwę projektu, wersję integracji i przybliżoną godzinę testu: to skraca drogę do odpowiedzi.