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: a422 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 toowner, 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.
Filtering
The filter bar narrows the list:- Method — one of GET, POST, PUT, PATCH, DELETE.
- Status — pick a class:
2xx,3xx,4xx, or5xx. - 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.
/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 inboundtraceparent 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 over SSE (the sample below); the full endpoint reference lives at 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.
Consuming the live-tail stream yourself
GET /api/v1/logs/tail returns an event-stream of the same rows, sub-second after each request completes. The caller must hold an owner, admin, or developer role, and the stream accepts a client-supplied Origin only when it is one of the Orbit console origins — set it explicitly, or skip this form and use the console toggle.
From a shell, stream rows as they complete — the TypeScript tab shows the same flow server-side with the eventsource package, since Node has no built-in SSE client that sets request headers:
data: line arrives on each completed request; : heartbeat comment lines arrive at least every 30 seconds on idle.
From the browser (the role of the console toggle), consume and filter — the TypeScript tab keeps only errors, mirroring the FAQ filter workflow:
connected handshake, log rows, heartbeat comments), resume via Last-Event-ID, and the 403/429/503 failure triggers.
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.
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.When the answer is an error code
A red 4xx or 5xx row in the table is only the start. Open the row, then read the response body’serror envelope:
error.code— the machine-readable string the runbooks index on. Paste it into the Error Code Reference or ask the Troubleshooting hub how to classify it (pre-send gate, transient, deterministic validation).error.details— the field-level hint (which input failed, what it expected). For tenant-owned pre-send rejects this is where the fix lives.meta.docs_url— a redirect to/errors/<CODE>, which resolves to the per-code anchor on the Error Code Reference page. Use it when you would rather land there directly.
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 readsmethod, 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
- API playground — build and run requests against the API from the dashboard, with generated curl/SDK code
- Developer Portal guide — try-it console, usage stats, key governance, webhook debugging
- Delivery Logs console — the downstream message lifecycle
- Log-tail API reference — consume the live request stream over SSE
- Operator observability map — which surface answers which question
- Per-domain data retention policy — scheduled purge windows you control
- Audit log — the durable configuration-change trail