Logs panel

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.

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

Three filters are visible above the list, plus a More filters dialog for everything else.

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

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

The detail panel shows the full request and response. The header strip carries the method, the path, and the status badge. Below that:

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

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.

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

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

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.

Where to next