API Request Logs
API Request Logs
API Request Logs capture the HTTP requests your backend makes against the Rutter API itself — POST /versioned/connections/create, GET /versioned/accounting/accounts, POST /versioned/accounting/bills, and so on. Different from Tool Call Logs, which capture what the agent does once it's connected to the MCP server.
You'll mostly use these when you're debugging your own integration code rather than the agent's behavior.
When to look at API logs vs Tool Call Logs
| Question | Look here |
|---|---|
| The agent called the wrong tool. | Tool Call Logs |
| The agent's tool call returned an error. | Tool Call Logs |
| My backend's request to create a connection is failing. | API Request Logs |
| Why did my Link URL request return 400? | API Request Logs |
| A webhook subscription update isn't taking effect. | API Request Logs |
| A tool call was blocked by confirmation. | Tool Call Logs |
What's captured
Per request:
- Method and path —
POST /versioned/connections/create,GET /versioned/accounting/accounts, etc. - Status code.
- Latency — total wall-clock time from receipt to response.
- Request body — sensitive values (API keys, secrets) redacted.
- Response body — full, post-redaction.
- API key prefix — the first few characters of the key used (so you can correlate against your secret store without exposing the full key).
- Source IP — useful when you have multiple backends sharing one key.
- Rutter version header — the
X-Rutter-Versionyour client sent. - Timestamp.
Filtering
The filter bar covers:
- Method (GET / POST / PATCH / DELETE).
- Path pattern — glob-style, like
/versioned/accounting/bills/*. - Status — success only, errors only, or specific codes.
- API key — narrow to one key (production, or a specific test key).
- Date range.
A common debugging shape: "all 4xx and 5xx responses on /versioned/connections/* in the last hour."
Drilling into a request
Click any row to open the full detail. You see:
- The full request URL with query parameters.
- The full request headers (
Authorizationredacted to its prefix). - The full request body.
- The full response status, headers, and body.
- The trace ID — useful when you want to file a support ticket; including this lets us find your request in our backend logs in seconds.
Common debugging flows
"My backend is creating connections that aren't appearing in the dashboard."
Filter to POST /versioned/connections/create, look at the response codes. If they're 200, check whether you're looking at the right environment in the dashboard (sandbox vs production). If they're 4xx, the response body says exactly what's wrong.
"My API calls were working an hour ago and now everything is 401."
Someone rotated the API key, or the X-Rutter-Version header is missing. Filter by API key prefix; if the prefix you're using doesn't appear in recent successful calls, the key was regenerated. Update your secret store.
"My webhook deliveries stopped."
Filter to the webhook subscription endpoints. If recent calls show 200 responses but no events are flowing, the issue is on the receiving side, not Rutter's side. The webhook delivery log has more detail on individual delivery attempts.
Retention
90 days on standard plans, longer on Enterprise. Bulk export is available for any filtered view. The logs aren't webhook-streamed today; for SIEM forwarding, pull via export or the API listing endpoints.
Next
For broken flows and error reference, see Troubleshooting & FAQ.