Request identity
Method, scheme, host, path, query string, tunnel name, and receive timestamp.
Requests
Inspect inbound requests with enough context to explain failures.
Request inspection in Binboi means more than printing a method and path. It means giving developers the metadata they need to answer what arrived, where it was routed, what the upstream service returned, and whether the error belongs to auth, transport, or application code.
Model
What request inspection means
A useful request view should help a developer reconstruct the life of one request without reading a whole stream of unrelated logs.
At minimum, the request view should tell you which tunnel received the request and which target service handled it.
It should show when the request arrived, how long it took, and what status code came back.
For webhooks, it should also preserve enough header and payload detail to explain signature and schema mismatches.
Current MVP note
In the repository today, the richest implemented visibility surface is still relay logs plus tunnel metadata. The full request-inspection experience described here is the product target the rest of the control plane is moving toward.
Metadata
What metadata should be visible
A developer-friendly request inspection surface should prioritize context that leads to action.
Headers
Forwarding headers, content type, provider-specific webhook headers, and trace-friendly identifiers.
Payload preview
Readable body previews that help debug shape mismatches without turning the UI into a data dump.
Target details
Which local service or upstream target handled the request and whether the route matched what the operator expected.
Timing
Duration, receive time, completion time, and clues about whether slowness came from the app or the network path.
Outcome
Status code, selected response headers, and a small response preview when it is safe and useful.
Response
Headers, payload previews, and response previews
The most useful request UIs help you compare inbound context and outbound response in one place.
Show headers that explain routing, auth, or provider intent.
Preview payloads at a size that is practical for debugging but still safe for operators.
Preview response status, timing, and any short body excerpt that explains whether the upstream app succeeded or failed.
Always include the target service identity so the operator knows which local process actually answered.
Errors
Useful error classifications
Classifying failures correctly is half the debugging battle.
Request error types
| Type | What it usually means | What to check first |
|---|---|---|
| `AUTH_ERROR` | The CLI token is invalid or the session could not authenticate. | `binboi whoami`, token status, API URL configuration. |
| `UPSTREAM_CONNECT` | The relay reached the agent, but the agent could not reach the local target. | Is the app listening on the expected port? |
| `UPSTREAM_TIMEOUT` | The request reached the app, but the app did not respond in time. | Long handlers, startup lag, database waits. |
| `HOST_MISMATCH` | The incoming host did not resolve to a valid or active tunnel. | Subdomain spelling, reserved tunnel state, domain config. |
| `WEBHOOK_SIGNATURE` | The request arrived, but signature verification failed in your app. | Signing secret, raw-body handling, middleware order. |
| `APPLICATION_500` | Your app ran and threw a failure. | Application logs, stack traces, route code. |