# Logs panel (/en/integrate/workbench/logs-panel) Every API request your account has made: method, path, status, headers, body, response. Filter by error, by resource, by source. The Logs panel is the request-level view of everything that's hit your account: every API call, every dashboard mutation, with method, path, status, request body, response body, headers, and error details if the request failed. It's the tool you reach for when an integration call returned a 400 and you want to see exactly what XPay received and what it answered. For the drawer mechanics (open, drag, full-screen), see [Workbench introduction](/integrate/workbench/introduction). ## Open the panel [#open-the-panel] Click the up-down arrows icon in the dashboard's bottom-right dock. The Workbench opens on the **Logs** tab pre-filtered to the last 24 hours. You can also open the Workbench any other way and switch to **Logs** in the tab bar. ## Filter the list [#filter-the-list] Three filters are visible above the list, plus a **More filters** dialog for everything else. | Filter | What it does | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Resource ID** | Free-text search. Find every request that touched a specific `pi_*`, `cs_*`, `cus_*`, etc. | | **Date** | Last N hours / days, on a specific day, between two dates. Defaults to last 24 hours when you open the panel from the dock icon. | | **Status** | **Succeeded** (2xx) or **Failed** (4xx and 5xx). Pick one to narrow the list. | | **More filters** (dialog) | HTTP method, API endpoint path, IP address, Source (Dashboard / API), error code, error type, error param. | A **Clear filters** button appears once any filter is set. The total count on the right (e.g. `42 logs`) reflects the filtered set. The "More filters" button shows a count badge (`+3`, `+5`) when extra filters are active so you don't lose track of what's narrowing the view. ## Reading the list [#reading-the-list] Logs are listed newest first, grouped under date headers (Today, Yesterday, then a date). Each row carries: * A status badge: `200 OK` (green) or `4xx ERR` / `5xx ERR` (red) with the actual code. * The HTTP method (color-coded per method). * The path (truncated to fit). * The time. Click a row to drill into the request. Use **Load more** at the bottom to page through history. ## Reading a request [#reading-a-request] The detail panel shows the full request and response. The header strip carries the method, the path, and the status badge. Below that: | Field | What it is | | ------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Request ID** | The `req_*` ID. Stable across retries. Quote this when reaching out for support. | | **Time** | Date and time of the request, second-resolution. | | **Duration** | Server-side response time in ms. | | **IP Address** | The client IP. Useful for tracing automated calls. | | **Origin** | The `Origin` header value, when present. | | **Idempotency Key** | The `Idempotency-Key` header value from the request, if you sent one. | | **API Key** | The first few characters of the secret key used, redacted. Lets you tell which key made the call without ever exposing it. | | **Source** | "Dashboard" (and the team-member name) for dashboard-driven mutations, otherwise an API call. | | **User Agent** | The client's `User-Agent` header. | If the request returned an error, an **Error Insight** section follows the metadata: the human-readable error message, plus the structured `errorType`, `errorCode`, and `errorParam` (each clickable as a quick filter). Below that, four payload sections render when present: * **Response Body**: the JSON XPay returned. For successful `GET` requests, the panel shows the literal note: "XPay doesn't store the response body from successful GET requests." Successful POST / PATCH / DELETE responses are stored. * **Request Body** (heading is `Request POST Body` / `Request PATCH Body` / `Request DELETE Body` depending on the request): the JSON you sent. * **Query Parameters**: the parsed query string, key by key. * **Request Headers**: every header XPay received, including the auth header (already redacted). Each section uses the same JSON viewer as elsewhere in the Workbench: keys are clickable, IDs are linked, and large objects collapse by default. ## Retention [#retention] API request logs are kept for **30 days**. After 30 days a row is physically pruned and disappears from the panel. The events panel and webhook deliveries have separate retention windows; see [Events panel](/integrate/workbench/events-panel). If you need request history past 30 days, ship your own logs from your server. The Workbench is a real-time debugging tool, not a long-term archive. ## A typical use [#a-typical-use] Three loops the Logs panel pays for: 1. **A live API call returned 400 and you want to know why.** Open the dock icon, the panel lands pre-filtered to the last 24 hours. Sort by `Status: Failed`. Click the row. The Error Insight section names the field that failed validation; the Request Body shows what you sent. 2. **Your retry logic doubled-up something.** Filter by `Idempotency Key` (or by `Resource ID` of the resource it affected). Compare the two rows side by side. The detail panel makes it obvious whether both succeeded or one was a no-op. 3. **A dashboard user changed something you didn't expect.** Filter `Source = Dashboard`. The Source field on each row tells you which team member made the change. ## Inspector context [#inspector-context] When the Logs panel renders inside the **Inspector** tab as a sub-tab (instead of as the top-level Logs tab), it auto-scopes to the resource you're inspecting. The Resource ID filter is hidden, and "Include related" is implicit so you also see logs that touched the resources around it (e.g. for a Payment Intent, logs that touched its Charges and Refunds). Same filters otherwise. See [Inspector](/integrate/workbench/inspector). ## Where to next [#where-to-next] The drawer mechanics, the four tabs at a glance, and how to open the Workbench. Drill into a single resource and see its logs, events, and the graph around it. Webhook events, deliveries, and attempts. The other half of the debugging story. Aggregate error groups across recent requests. The error envelope, the full list of `errorCode` and `errorType` values, and how to handle them. What the `Resource ID` filter accepts and how the resources fit together.