Request Viewer
Inspect every HTTP request FileRelay received — method, path, status, headers, request body, response body, duration. The audit trail for ingest.
The Request Viewer (/requests) is a chronological log of every inbound HTTP request FileRelay has captured for the current workspace — ArchiveLink calls from SAP, OData / CMIS webhooks, ad-hoc curl pokes, anything that hit the workspace's endpoint URL.
It's the first place to look when "SAP says it sent the doc but FileRelay didn't" or "delivery to destination X is failing — what did we actually receive?".
What gets captured
Every request that lands on the workspace's ingest URL is logged with:
| Field | Notes |
|---|---|
| HTTP method | POST, PUT, GET, HEAD, etc. |
| Path + query | Full request URI, including any ?docId=...&contRep=... query string from ArchiveLink. |
| Status code | The response FileRelay returned (201 Created, 400 Bad Request, …). |
| Duration | Time spent inside the handler in milliseconds. |
| Request headers | Authorization, X-AccessMode, signatures, content-type, etc. |
| Request body | The bytes SAP / the source sent. Stored as binary; downloadable. |
| Response headers | What FileRelay sent back. |
| Response body | The body FileRelay returned (typically empty for 201, an error message for failures). |
| Timestamp | When the request landed. |
Bodies are stored as bytea in Postgres and offered as downloads — neither is rendered inline because raw PDFs or 50 MB TIFFs would freeze the browser.
The list
The left panel is a chronological list (newest first) with one row per captured request:
- Method + path — at a glance, what was called.
- Status pill — green for 2xx, amber for 4xx, red for 5xx.
- Duration — small grey timing badge.
- Timestamp — relative ("3 min ago") on hover for absolute.
Click a row to open it in the detail panel on the right.
The detail panel
A request's detail view has four tabs:
- Overview — method, path, status, duration, timestamp, source IP.
- Headers — both request and response headers as key:value tables.
- Body — download buttons for the raw request and response bodies. Sizes shown in human units (
12.4 KB,2.1 MB). - Linked document — if this request resulted in a
documentsrow, a link to the document detail page.
Filtering & pagination
The page paginates with a before cursor (timestamp-based, stable under inserts). Scroll to the bottom and click Load more to fetch the next page.
There is no client-side filter yet — if you need to find one specific request, the URL accepts a request id: /requests/{id} jumps straight to it.
Clearing the log
The Clear captured requests button at the top wipes every captured request for the current workspace. Use it after a debugging session — the table can grow large.
- Wipe is per-workspace — other workspaces are untouched.
- It's permanent — there is no soft-delete.
- The corresponding
documentsrows are not affected; only the request capture rows.
Permissions
Captured requests can contain sensitive bytes (the document body, auth headers). Access is gated by the same manage-resources policy as the rest of the workspace admin area — workspace owners and admins only.
Retention
There is no automatic retention policy yet. Captured rows persist until you click Clear. Plan: a workspace-level "auto-purge after N days" knob is on the roadmap.
Troubleshooting recipes
| Symptom | What to look for |
|---|---|
| SAP says it sent a doc, FileRelay never got it | The Request Viewer is empty — issue is between SAP and FileRelay (DNS, TLS, firewall). |
Doc arrived but no documents row |
A captured row with status 4xx — open it and read the response body for the validation error. |
| Delivery fails immediately | Open the document via the Linked document tab, then check the destination's most recent error from there. |
Mysterious 400 invalid signature |
Open the request, copy the X-FileRelay-Signature header value, and confirm it matches what your client computed. |
See also: Document Detail Page — the other half of the audit trail.