Skip to main content

​
Inspect API payloads in Request Logs

The Developer → Request Logs page is the dashboard surface for answering “what exactly did my integration send, and what came back?” It lists every API call handled for your workspace — method, path, status code, latency, the API key that authenticated it — and opens any row to show the full request and response payloads. Use it when the operator question is about HTTP traffic: a 422 you did not expect, a key sending something it should not, a latency spike on one route. For the downstream question “what happened to the message after the API accepted it,” use Delivery Logs instead — the two pages answer different questions and are most useful together.

​
Access and roles

The page is gated to owner, admin, or developer roles. Rows carry the full request and response bodies, which can include phone numbers, message text, contact payloads, and authorization headers — the same PII tier as API keys and webhooks, so viewer, billing, and agent roles cannot open it. Manage that access the same place you manage API keys (see the API key usage limits guide).

​
Reading the table

Each row is one API request:
  • Timestamp — rendered in your own timezone.
  • Method — GET, POST, PUT, PATCH, DELETE, color-coded (green GET → cyan POST → amber PUT/PATCH → red DELETE).
  • Path — the route that was called.
  • Status — the HTTP status code; 2xx green, 3xx cyan, 4xx amber, 5xx red.
  • Latency — end-to-end request time in milliseconds.
  • API key — the key that authenticated the call, masked.
  • Size — response payload size.
Above the table, four summary cards track Total Requests, Success Rate, Avg Latency, and Error Count for the current window. With no filters active, the Total, Success Rate, and Error cards come from the request-analytics overview; Avg Latency is computed from the loaded rows themselves. Once any filter is active, all four cards describe the filtered sample — expect them to move as you narrow.

​
Filtering

The filter bar narrows the list:
  • Method — one of GET, POST, PUT, PATCH, DELETE.
  • Status — pick a class: 2xx, 3xx, 4xx, or 5xx.
  • Path — free text, debounced; matches route fragments such as /messages.
  • API key — match by key prefix (for example dv_test_…) to isolate one integration.
  • Request ID — paste a full request id to jump straight to that one call.
The Clear filters button resets everything — including the date range — back to the default view. The page opens on the last 30 days. The date-range picker offers preset windows plus a custom calendar range; custom ranges can reach back one full year, which is the retention horizon. The page accepts deep links: /developer/request-logs?method=POST&path=/messages&status=5xx opens already scoped — the API-analytics endpoint cards link here this way.

​
Inspect a payload

Click a row (click, or Enter/Space with keyboard focus) to open the detail drawer. It shows status, latency, size, timestamp, source IP, the masked API key, and — when present — the Trace ID. Orbit honors an inbound traceparent header or mints a W3C trace id, returns it on the response traceparent header, and attaches it to related webhook deliveries, so you can follow the request into your own tracing backend. Below the meta grid, the drawer renders Request Headers, Request Body, Response Headers, and Response Body blocks with a copy button each. Keep the redaction model straight: what shows as masked or redacted — the API key prefix, sensitive header values — was masked before it was written to the log, so nothing you can copy from the drawer exposes the raw credential. Treat the drawer as PII-bearing anyway and prefer the copy button over screenshots when sharing with support.

​
Live tail, exports, and pagination

  • Live tail — the toggle in the header opens a streaming connection and prepends every request to the top of the table as it completes, for live debugging. It caps at the 500 most recent rows. The same stream is consumable from your own tooling — see the Log-tail API reference.
  • Export — downloads the current filtered result set as CSV (timestamp, method, path, status, latency, masked key, size). The export walks the whole result, not just the loaded page, up to a 100,000-row cap; the toast reports if the cap truncated the file.
  • Pagination — the table pages 50 rows at a time; Load more appends a page under your active filters without a full reload.

​
Where this page fits against other surfaces

Orbit offers several observability surfaces and they answer different questions:
  • This page (Request Logs) — historical request inspection with full payloads, up to a year back.
  • Live tail toggle / GET /logs/tail — the in-flight request stream, for live debugging only.
  • Events firehose — a bounded, in-memory buffer of workspace events (message sent, agent run, contact updated) with about a 15-minute TTL. Not durable, not an audit log.
  • Audit log — the durable trail of configuration changes (who changed what setting, when). It records actions, not request payloads.
  • Delivery Logs — the downstream lifecycle of a message after the API accepted it.
For the full map — moment-lookup vs trend-level vs durable-record surfaces — see the operator observability map.

​
Retention

Request rows are retained for one year. Custom date ranges older than a year return no aged-out rows, and the empty state in that case tells you the requests aged out rather than asking you to widen the range. The summary overview cards (unfiltered view) are served from a 30-day metric window — different machinery, so do not read one window against the other.

​
When a key is no longer trusted

If the requests you are inspecting came from a key you no longer want active, revoke it from Settings → API keys rather than inspecting further. If the concern is longer-lived data — request payloads, message bodies, audit entries — the purge controls you own are in the per-domain data retention policy, which sets scheduled redaction and deletion windows per record class.

​
Frequently asked questions

​
The table is empty, but I know I made API calls

Check the filters first — an active method/status/path/key/request-id filter or a narrowed date range zeroes the table, and the empty state tells you whether it is a filter miss or genuine first use. A custom range starting before the one-year retention boundary can never return the aged-out portion; pick a more recent start date. If the page still shows nothing while the analytics overview reports traffic, use the Retry button — the historical rows come from a query backend that can return empty on a transient slowdown.

​
Why does the Avg Latency card show an em-dash?

An em-dash means no rows are loaded to average — the card refuses to fabricate a zero. Retry, or widen the range until rows load.

​
Can I hand teammates a pre-filtered view?

Yes. The page reads method, status, and path from the URL on open, and values outside the valid sets are ignored — shareable scoped links without a saved-view feature.

​
See also