GET /v1/limits

What this tenant may send. An integration reads its budget once at startup and then knows, before it builds an event, whether a 40 MB PDF will be accepted or whether inline video is allowed at all.

GET {base_url}/v1/limits
Authorization: Bearer ogr_<key>

Response — 200

{
  "limits": {
    "max_request_bytes": 67108864,
    "media": { "image": 8388608, "audio": 8388608, "document": 16777216,
               "file": 8388608, "video": 0 },
    "media_parts_max": 16
  }
}

The same object is echoed on every heartbeat, so a long-running integration learns about a change within one interval without polling.

The two bounds are different answers, and mixing them is the mistake

• Over max_request_bytes ⇒ a hard 413, and the whole event is refused. The check happens on Content-Length and again while reading, because checking after the body is buffered is the same as having no limit.
• Over a per-kind media cap ⇒ the PART is DECLINED, the event is accepted. The descriptor is kept, the path is reported in the verdict's unjudged, and the console marks it uninspected.

A 4xx on the second case would make an integration either break the turn or fail open — and a fail-open leaves no record at all, which is strictly worse than an honest "this part was not inspected".

⚠️ A modality allowance is a byte cap, never a boolean. media.image = 0 IS the text-only tier. A modalities: ["text"] list would be a feature flag wearing a limits name, and the next reader gates a whole code path on it.

⚠️ Elide, do not truncate. An integration that drops an oversized part must replace the value in place rather than removing the element: dropping it shifts every later array index, and a verdict span computed behind it still resolves — onto the wrong string.

Errors