The Request logs tab of the
Developer Hub shows your
organization’s /v1 API traffic: summary statistics for the last 24 hours —
request count, error rate, and rate-limited requests — above a searchable
log of individual requests.
What each entry records
The log table shows the time, HTTP method, path, response status, policy
decision, latency, and request ID of each call. Opening an entry shows the
full detail, including the service account and API key that made the call,
the source IP, and the permissions that were in effect.
The policy decision tells you how the request was handled:
- Allowed — the request was authenticated and authorized.
- Denied — the request was refused, for example because the key lacked
the required permission, had expired, or was revoked.
- Rate limited — the request exceeded a request budget and was refused
with a
429. See rate limits.
Filter and search
Narrow the log by service account, API key, HTTP method, status class
(2xx–5xx), policy decision, time range, or path prefix (for example
/v1/entities).
Trace an error by request ID
Every API response carries a Request-Id header, and every error body
carries the same value in its request_id field. Paste that value into the
request log search to jump straight to the matching entry and see exactly
how the request was handled.
When an integration reports an error, ask for the request_id from the
error response. It is the fastest path from a customer-side symptom to the
authoritative record of what happened — and the value to include if you
contact Living Security support.
Spot problems early
- A rising error rate usually means a key expired, was revoked, or lost
a permission it needs — filter by decision to find the failing credential.
- A rising rate-limited count means a workload is running hot; see
rate limits for smoothing strategies.
- Traffic from a service account that should be idle is a signal to check
whether its credentials are where you think they are — and to
disable the account while
you investigate.
