> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Request Logs

> Trace, filter, and troubleshoot your organization's Living Security Public API traffic from the Developer Hub.

The **Request logs** tab of the
[Developer Hub](/developers/developer-hub/overview) 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](/developers/v1/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.

<Tip>
  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.
</Tip>

## 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](/developers/v1/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](/developers/developer-hub/service-accounts) while
  you investigate.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.