Developer errors
Inspect both HTTP status and response body. The current routes do not all share the nested error envelope shown in older documentation.
REST examples
Section titled “REST examples”{"error":"insufficient scope"}Some routes also include error_code or detail:
{"error":"this key may not manage keys","error_code":"insufficient_scope"}| Status | First action |
|---|---|
| 400 | Correct the request fields before trying again. |
| 401 | Check that the key is present, active, and unexpired. |
| 403 | Check ownership, scopes, and the operation’s requirements. |
| 404 | Check the route and resource; old app-lifecycle routes are absent. |
| 409 | Inspect the conflicting state or request identifier. |
| 429 | Honor a supplied retry delay and use bounded backoff. |
| 5xx | Check whether a mutation already took effect before retrying. |
Include the operation, time, status, and any returned request identifier in a support report. Do not include the bearer token.
MCP and A2A
Section titled “MCP and A2A”MCP protocol errors use JSON-RPC errors. A tool execution failure can instead be a tool result with isError: true and text content. Check both levels.
A2A uses JSON-RPC responses, but the current card advertises no app-building skills. A recognized protocol endpoint does not imply an implemented task.
Rate limits · MCP · A2A