> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beta.b3os.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Request log

Look up any request by its ID to see where its time went, or list recent requests by product, status, key, connection or sandbox, for 7 days.

The node records every request it serves, whichever way it arrived: through the edge, from inside a sandbox, or from a tool on the node. Each record has the request's status, size, duration and timing phases, and the edge adds its own phases under the same ID. Records are kept for 7 days. Both calls need `platform:read`.

## Look up one request

Every response carries `x-request-id`, and every problem repeats it as `instance`:

**curl**

```bash
    curl -s "https://beta-api.b3os.org/v1/requests/$REQUEST_ID" \
      -H "Authorization: Bearer $B3OS_API_KEY"
    ```
  **TypeScript**

```ts
    const record = await b3os.requests.getRequest(requestId);
    for (const phase of record.phases) console.log(phase.source, phase.name, phase.duration_ms);
    ```
  **Python**

```python
    record = b3os.requests.get_request(request_id)
    for phase in record["phases"]:
        print(phase["source"], phase["name"], phase["duration_ms"])
    ```
  **MCP**

No MCP tool reads the request log. Fetch the record from code or with `b3os api GET /v1/requests/$REQUEST_ID`, paste it into the conversation, and ask the agent where the time went.

| Field | Meaning |
|---|---|
| `method`, `path`, `operation_id`, `product` | What was called; the path has no query string |
| `status_code`, `error_code` | The response status, and the problem's `code` when it failed |
| `org_id`, `project_id`, `key_id` | Who called. For calls from a sandbox, `key_id` is the key that created the sandbox. |
| `node` | The node that served it; `null` when the edge answered by itself |
| `connection` | `edge`, `sandbox`, `uds` (the node's Unix socket) or `tcp` (the node's loopback port) |
| `sandbox_id` | The calling sandbox, for `sandbox` connections |
| `started_at`, `duration_ms` | Start time, and first request byte to last response byte, measured on the node (for streams, until the stream ended) |
| `request_bytes`, `response_bytes` | Body sizes |
| `phases` | The node's phases (`source: node`) and the edge's `edge_auth` and `edge_upstream` (`source: edge`), in order |
| `trace_id` | The W3C trace ID from the `traceparent` you sent |
| `user_agent` | The client's user agent |

For a request the edge answered itself, such as key management or a request refused before forwarding, the edge returns its own record: `node` is `null` and only edge phases appear.

## List recent requests

`GET /v1/requests` lists the node's records for your project, newest first:

```bash
curl -s -G https://beta-api.b3os.org/v1/requests \
  -H "Authorization: Bearer $B3OS_API_KEY" \
  -d product=vision -d status=5xx -d limit=50
```

| Filter | Example |
|---|---|
| `product` | `vision` |
| `operation_id` | `visionScrape` |
| `status` | `2xx`, `4xx` or `5xx` |
| `key_id` | `key_01m5t5csy2wt4e3er052chyf1x` |
| `connection` | `sandbox` |
| `sandbox_id` | All calls one sandbox made |
| `since` | An RFC 3339 time |

The list holds what the node served. Requests the edge answered without forwarding are not listed; fetch those by ID. [Timing](/concepts/timing) explains how to read the phases.