Verify an API key
Validate an API key and return its metadata.
Validate an API key and return its metadata.
Your API key as a bearer token.
In: header
Response Body
application/json
application/json
curl -X POST "https://example.com/verify"{
"valid": true,
"key": {
"id": "string",
"name": "Production key",
"enabled": true,
"rateLimitEnabled": true,
"requestCount": 42,
"remaining": 0,
"expiresAt": "2019-08-24T14:15:22Z",
"metadata": {}
},
"gateway": {
"region": "string",
"url": "string"
}
}{
"error": "Invalid API key",
"code": "INVALID_API_KEY",
"retryAfter": 0
}Subscribe to a session's live event stream GET
Server-Sent Events. Every scan (`/scan`, `/rag/*`, `/agent/*`) that carries the same `session_id` publishes a compact decision summary here the moment it's made (no scanned text, tool arguments, or redacted content ever appears on this stream, only the decision itself). This is what the SDK's `subscribe()` connects to. Three event shapes appear as `data:` frames, distinguished by `stage`: - A decision (`stage`: `prompt`, `rag`, `tool`, or `response`): `action`, `risk` (0-100), `latency` (ms), the policy directives that fired, a `job_id`, and a `pii` summary when any was found. `action` is the engine's label (lowercase, so `review` appears here). `needs_review` (boolean) and `enforced_action` (`allow` or `block`, the action the gateway enforced after applying your app's `reviewCollapse` setting) are added from the `review_flag` release onward. `tool`/`rag` stages also carry `phase` (`call`/`output` or `chunk`/`context`) and, for `tool`, the tool name. - `{"stage": "audit", "id": "<job_id>"}`: sent once that job's decision has been durably persisted, always after that job's decision event. - `{"stage": "_meta", "dropped": <n>}`: this connection fell behind and missed `n` events; never sent silently. The connection is long-lived: it stays open with periodic keep-alive comments until the caller disconnects. Capped at 40 concurrent connections per organization.
List knowledge buckets GET
Lists the knowledge buckets of the app the API key belongs to, with the number of documents currently served from each. The key must be tied to an app; the app is taken from the key, never from the request.