Request logs

curl "https://api.integrable.cloud/api/logs?limit=20" \
  -H "Authorization: Bearer $INTEGRABLE_API_KEY"

{
  "items": [
    {
      "id": "01a0670f-...",
      "request_id": "7cb7f7862a82425d8e4c3fb8a497dfe6",
      "method": "POST",
      "path": "/bots/{bot_id}/knowledge",
      "status_code": 402,
      "duration_ms": 118,
      "error_code": "quota_exceeded",
      "ip": "203.0.113.24",
      "user_agent": "integrable-cloud-python/0.1.0",
      "idempotency_replayed": false,
      "created_at": "2026-09-03T14:22:09.481Z",
      "api_key_id": "01a0654a-...",
      "api_key_name": "CRM sync"
    }
  ],
  "has_more": true,
  "next_cursor": "eyJrIjoiMjAyNi0wOS0wM1QxNDoyMjowOVoi..."
}

Newest first, cursor-paginated. Follow next_cursor — there is deliberately no total, because counting this table exactly means scanning the fastest-growing thing your workspace owns to produce a number nobody acts on.

Every API response carries an X-Request-ID. Feed it back and you get that exact call:

curl "https://api.integrable.cloud/api/logs?request_id=$REQUEST_ID" \
  -H "Authorization: Bearer $INTEGRABLE_API_KEY"

This is also what to quote at support — we look up the same row, so there is no round of “can you reproduce it”.

4xx and 5xx are worth separating rather than filtering on errors: a 4xx is something your client sent, a 5xx is ours.

curl "https://api.integrable.cloud/api/logs/summary?hours=24" \
  -H "Authorization: Bearer $INTEGRABLE_API_KEY"

{
  "requests": 1842,
  "errors": 37,
  "server_errors": 2,
  "rate_limited": 11,
  "replays": 4,
  "keys_used": 3,
  "avg_ms": 96,
  "p95_ms": 412,
  "error_rate": 0.0201,
  "window_hours": 24,
  "endpoints": [
    { "method": "GET", "path": "/bots/{bot_id}/conversations",
      "requests": 1204, "errors": 3, "avg_ms": 88 }
  ]
}

p95_ms alongside the mean on purpose: a mean hides exactly the case you are debugging, which is a call that is usually fast and occasionally is not.

rate_limited is the one to watch in a batch job. If it is climbing, read the RateLimit-* headers and slow down — see rate limits.

• Only API-key traffic. Requests made by the dashboard are not logged — they are not your integration, and logging them would bury the rows you came here to find.
• No bodies, ever. Not the request, not the response. On a failure the machine-readable error_code is stored but never the message, because a message can quote your own data back.
• The templated path (/bots/{bot_id}), not the concrete one. The specific id is in the call you made; the pattern is what makes “which endpoint is slow” answerable.

Export anything you need to keep longer — the log is for debugging, not an archive.

Reading the log requires an admin seat. It names every endpoint your integrations touch and the addresses they call from, which is closer to how your systems are wired than to ordinary workspace data.