# Inspecting Requests

Every production API call and webhook delivery flows into the dashboard’s [Logs](/logs) and [Activity](/activity) surfaces. This page is the field glossary plus a short “I made a call that returned 500—what next?” walkthrough.

Sandbox calls are free and unmetered. They run on an isolated service that records no request logs and no usage counters, so they do not appear on either surface — inspect them from your own client’s output instead.

## Field glossary

Both Logs and Activity rows expose the same identifiers. Knowing which one to grep is the difference between “I see the call but not the webhook” and a closed-loop debug.

- `request_id`
  - The persistent id of the API call record. Stable across the row’s lifetime.
  - where: Logs row, Logs drawer “Overview” tab, /logs/:request_id permalink URL.
- `correlation_id`
  - The id of the inbound HTTP envelope. Every webhook delivery triggered by an API call carries the same `correlation_id`, which is how Activity rows link back to the originating Logs entry.
  - where: Logs drawer “Overview”; Activity drawer “Overview” (with a “View in Logs” link).
- `idempotency_key`
  - The `Idempotency-Key` request header you sent. Clicking the chip in a Logs row filters the list to every retry of the same logical operation. See [Idempotency](/docs/concepts/idempotency).
  - where: Logs row (chip), Logs drawer “Related” tab.
- `auth_mode`
  - Which auth surface the request used: `client_credentials` (real B2B integration traffic; the default Logs filter), `session` (portal cookie / Bearer JWT), or `public` (anonymous).
  - where: Logs drawer “Overview” tab; Logs filter dropdown.
- `delivery_group_id`
  - Identifies a single (event, subscriber endpoint) pair. Retries of the same delivery roll up under one delivery_group_id.
  - where: Activity drawer “Overview” tab; the /activity/:event_id permalink uses it.
- `attempt_number`
  - Which retry attempt this row represents. Attempt 1 is the original; higher numbers are exponential-backoff retries.
  - where: Logs drawer “Webhook deliveries” tab; Activity drawer “Deliveries” tab.
- `environment`
  - Which client_secret env wrote the row: `sandbox`, `development`, or `production`.
  - where: Logs drawer “Overview”; TopBar env switcher filters both Logs and Activity by this.

## Walkthrough: a call that returned 500

1. Open [Logs](/logs). The list defaults to `auth_mode=client_credentials` so portal traffic doesn’t drown out integration calls.
2. Click the failing row. The drilldown drawer opens with the Response tab pre-selected on 4xx/5xx and the status badge colored per the response code. The URL updates to `/logs?id=req_xyz` — share that link in Slack and your teammate lands on the same view.
3. The **Response** tab shows the redacted response body. The **Request** tab has a “Copy as cURL” button that reconstructs a runnable curl with `Authorization: Bearer $YOUR_KEY` (we never write the real key to your clipboard).
4. If the request triggered webhooks, the **Webhook deliveries** tab lists every attempt with status, latency, and a “View in Activity” link that opens `/activity/:delivery_group_id`.
5. If the call had an `Idempotency-Key`, the **Related** tab shows every other request that used the same key (newest first, capped at 20).

## Permalinks

Two URL shapes resolve to the same data — pick the one that matches the surface you want to share.

- `/logs/{request_id}` — Full-page view of one request. Best for Slack / support tickets.
- `/logs?id={request_id}` — List view with drawer open on the same request. Best for triage.
- `/activity/{delivery_group_id}` — Full-page view of one event group (every attempt for one subscriber).