Skip to content

Maker-checker over the API

Four-eyes control is not a UI feature layered on top. It lives in the platform, so it applies to your API integration exactly as it applies to the console. This page is what that means for your code.

The 202 you must handle

When you submit a write that exceeds a configured threshold (a large transfer, a manual journal, a loan approval), the operation does not execute inline. Instead it returns:

202 Accepted
{ "approvalId": "apr_01J…", "status": "PENDING_APPROVAL" }

Cortex has serialised your exact command into an approval record. A checker (a different human, with the right permission and tier) later approves it, and your original command is replayed and takes effect. Below the threshold, the same call settles inline with 200/201.

So your client must treat 202 as a first-class outcome, not a success-or-error binary:

Response Meaning Your move
200 / 201 Executed inline Done.
202 + approvalId Parked for a checker Record the approvalId; poll or wait for the decision.
4xx Rejected Fix and resubmit.

Tracking the decision

Read the approvals API to follow an item to its conclusion:

  • GET /api/v1/approvals: the queue. Filter to what is relevant to your integration (approval:view; oversight across all needs approval:view-all).
  • The item ends approved (your command executed; the result is now visible on the underlying resource) or rejected (with a reason).

The four-eyes rule is enforced server-side: the identity that made a request cannot decide it. An integration cannot approve its own submissions.

Who decides, and when

Which operations require approval, above what amount, and how many approvers of what tier, is configured in /api/v1/approval-policy (editing needs admin:users; changes take effect immediately). Your integration does not choose whether four-eyes applies; the policy does. Design for the possibility that any qualifying write comes back as 202, because an administrator can lower a threshold at any time.

The same seam covers agents

The AI agent gateway reuses this exact approval mechanism. An agent cannot escape four-eyes by going through MCP instead of REST. A parked action comes back to it as a PENDING_APPROVAL result with the same approvalId.