Skip to main content
Fliken Request logs i Developer Hub visar din organisations /v1 API-trafik: sammanfattande statistik för de senaste 24 timmarna – antal begäranden, felfrekvens och hastighetsbegränsade begäranden – ovanför en sökbar logg över enskilda begäranden.

Vad varje post registrerar

Loggtabellen visar tidpunkt, HTTP-metod, sökväg, svarsstatus, policybeslut, svarstid och begärande-ID för varje anrop. När du öppnar en post visas alla detaljer, inklusive det tjänstkonto och den API-nyckel som gjorde anropet, käll-IP-adressen och de behörigheter som gällde. Policybeslutet anger hur begäran hanterades:
  • Allowed – begäran autentiserades och auktoriserades.
  • Denied – begäran nekades, till exempel därför att nyckeln saknade den behörighet som krävdes, hade upphört att gälla eller hade återkallats.
  • Rate limited – begäran översteg en begäransbudget och avvisades med 429. Se hastighetsbegränsningar.

Filtrera och sök

Avgränsa loggen efter tjänstkonto, API-nyckel, HTTP-metod, statusklass (2xx–5xx), policybeslut, tidsintervall eller sökvägsprefix (till exempel /v1/entities).

Spåra ett fel med begärande-ID

Varje API-svar innehåller en Request-Id-header, och varje felmeddelande innehåller samma värde i sitt request_id-fält. Klistra in värdet i sökfältet i begäranloggen för att gå direkt till motsvarande post och se exakt hur begäran hanterades.
När en integration rapporterar ett fel ska du be om request_id från felsvaret. Det är den snabbaste vägen från ett symptom hos kunden till den auktoritativa posten över vad som hände – och det värde du ska uppge om du kontaktar Living Securitys support.

Upptäck problem tidigt

  • En stigande felfrekvens betyder vanligtvis att en nyckel har upphört att gälla, har återkallats eller har förlorat en behörighet som den behöver – filtrera på beslut för att hitta den felande inloggningsuppgiften.
  • Ett stigande antal hastighetsbegränsade begäranden betyder att en arbetsbelastning går för hårt; se hastighetsbegränsningar för strategier för utjämning.
  • Trafik från ett tjänstkonto som borde vara inaktivt är en signal om att kontrollera om kontots inloggningsuppgifter finns där du tror att de finns – och att inaktivera kontot medan du utreder saken.