Approval Routing

When BobSentry returns REQUIRE_APPROVAL, the integrator must not perform the downstream mutation until a human authorizes it. Approval authorizes the integrator to proceed — it is not execution proof, and BobSentry does not run the downstream action.

1. 1. Evaluate. Call POST /v1/runtime/evaluate with x-api-key. On REQUIRE_APPROVAL, note decision_id and approval_status (typically PENDING).
2. 2. Do not execute. Hold the downstream mutation (deploy, migrate, send, delete, …).
3. 3. Human resolves. An authorized operator reviews the request in the BobSentry Approvals console (or equivalent authorized console/API path). Evaluation credentials cannot self-approve.
4. 4. Poll status. Integrator checks GET /v1/runtime/decisions/:decisionId with the same API key until approval_status is terminal (APPROVED, DENIED, or EXPIRED).
5. 5. Proceed only if authorized. After approval, decision remains REQUIRE_APPROVAL and approval_status becomes APPROVED. Proceed when decision == ALLOW or (decision == REQUIRE_APPROVAL and approval_status == APPROVED). On PENDING / DENIED / EXPIRED / BLOCK, do not proceed. Do not wait for is_allowed / isAllowed to become true after approval. Optionally record an execution outcome later — that is separate from authorization.

There is no automatic resume or BobSentry-driven execution callback in this flow. Hands-on walkthrough: Protect a production deployment. Contract detail: Runtime Integration Contract.