Approvals and Retries

Applicability

This workflow applies only to tenants with enterprise control approval enabled. Other tenants retain immediate writes. Read-only balance monitoring does not require approval.

On APPROVAL_REQUIRED, read data.operation and executed:false, then open operation.approvalPath on the trusted console origin for human owner approval.
Machines cannot approve on behalf of the user or use a management key on human approval endpoints.
Reuse the same idempotency key for retries of the same intent. Do not change it after a timeout to repeat a creation. Changed intent yields CONTROL_IDEMPOTENCY_CONFLICT.


POST	`/enterprise/v1/operations`	Submit an operation
GET	`/enterprise/v1/operations/{id}`	Read status
POST	`/enterprise/v1/operations/{id}/cancel`	Cancel a pending operation

Only the originating key and its owner identity may access an operation; use the operation UUID. Submit action, parameters, and idempotencyKey. HTTP 202 with code:200 means acceptance, not execution.

Supported actions: create_sub_account, set_sub_account_status, delete_sub_account, set_sub_account_model_access, create_sub_account_api_key, update_sub_account_api_key, delete_sub_account_api_key, and provision_sub_account. Corresponding member/policy/key write scopes are required; composite provisioning needs all three.

Composite provisioning parameters contain member, modelAccess, and key, creating the member, policy and inference key in one operation. Arbitrary action sequences and machine-provided passwords are not supported.

Status queries do not return plaintext credentials. One-time credentials returned by successful human execution are not replayed on polling or repeated approval. After a lost response, query status before taking another action; do not recreate the member.

MCP at /enterprise/mcp follows the same scope and approval boundaries but uses a different protocol. Approval-required writes return isError:true, error.code:APPROVAL_REQUIRED, operation, and executed:false. Do not send a REST JSON example as an MCP request.

Action parameters

Except create_sub_account (creation body only), for single-resource actions parameters contains the corresponding endpoint body plus subAccountId from its path. Key update/delete also requires hash. Member deletion needs only subAccountId; key deletion needs subAccountId and hash.

status: pending_approval, succeeded, failed, rejected, cancelled, expired. executed=true only for succeeded.

JSON

1{
2  "action": "provision_sub_account",
3  "parameters": {
4    "member": {
5      "username": "team_app"
6    },
7    "modelAccess": {
8      "restriction": "INHERIT"
9    },
10    "key": {
11      "name": "service-key",
12      "spendLimit": 100,
13      "limitReset": "monthly"
14    }
15  },
16  "idempotencyKey": "provision-team-app-001"
17}