Request IDs and logs
Reference article: Part of the API reference.
Every response carries a Request-Id header, such as req_nn1fXk2LmQ8rT4vW6yZ0aB3c, and every error body repeats it as request_id. It identifies one request end to end: log it next to your own records, and quote it when you contact support.
::: code-group
curl -sD - -o /dev/null https://api.gonimbus.ai/v1/whoami \
-H "Authorization: Bearer $NIMBUS_API_KEY" | grep -i request-id
# request-id: req_nn1fXk2LmQ8rT4vW6yZ0aB3c
const response = await fetch('https://api.gonimbus.ai/v1/whoami', {
headers: { Authorization: `Bearer ${process.env.NIMBUS_API_KEY}` },
})
console.log(response.headers.get('Request-Id'))
response = requests.get(
"https://api.gonimbus.ai/v1/whoami",
headers={"Authorization": f"Bearer {os.environ['NIMBUS_API_KEY']}"},
)
print(response.headers["Request-Id"])
:::
The header is exposed to browsers through CORS, so front-end code can read it too.
Watching traffic on the Developers page
The Developers page in Nimbus shows every request made with your organization's keys. Organization admins can open it from the sidebar.
API usage summarizes a time range, 24h, 7d, or 30d, for all keys or one:
| Panel | Shows |
|---|---|
| Requests | Total requests in the range, with a trend line. |
| Error rate | The share of requests that failed (status 400 or above), and how many. |
| Latency p95 | The response time 95% of requests beat, with the median (p50) beneath. |
| Requests chart | Succeeded and failed requests per hour (24h) or per day (7d, 30d), with p95 latency over time. |
| Top endpoints | The busiest endpoints, with their error rate and p95 latency. |
| Top errors | The most frequent error codes. |
Request log lists requests newest first. Filter to All, Succeeded, or Failed, and scroll to load more. Select a request to see its details:
| Detail | Description |
|---|---|
| Request ID | The Request-Id of the request. |
| Status and error | The HTTP status and, for failures, the error type, code, and message. |
| Time and duration | When the request arrived and how long the API took to answer. |
| API key | The name and ID of the key that sent it. |
| API version | The version it was served with. |
| Route | The endpoint pattern, such as /runs/:id, which groups requests for different objects. |
| Idempotency key | The Idempotency-Key header, if the request sent one. |
| Source IP and user agent | Where the request came from. |
Request bodies and responses aren't stored, so nothing sensitive you send is kept in the log.
What gets logged
Every request that names a real key is logged, whatever its outcome, including requests refused because the key was revoked or expired, lacked a scope, or was rate limited.
Requests with a missing or unknown key aren't logged, because they can't be tied to your organization. They still get a Request-Id.
Example scenario
A partner reports that posting updates stopped working overnight. An admin opens Developers, sets the range to 24h, and sees the error rate jump at 02:00. Filtering the request log to Failed shows every failure is 401 api_key_expired from the key Partner sync: it was rolled with a 24-hour grace period and the partner never deployed the new key. The admin sends them the new key and the error rate drops to zero.
FAQ
Can I get request logs through the API?
Not yet. They're on the Developers page today.
Are request bodies stored?
No. The log records the method, path, status, timing, key, and error details, never the body you sent or the response.
Why doesn't a request I sent appear in the log?
It probably had a missing or mistyped key, so it couldn't be tied to your organization. The response's error code will be missing_api_key or invalid_api_key.
How current are the metrics?
Requests appear within moments of finishing. Use the refresh button on the Developers page to reload.
What's the difference between the path and the route?
The path is the exact URL, such as /v1/runs/run_4Kp9Qz. The route is its pattern, such as /runs/:id, which is how Top endpoints groups requests for different objects together.