Skip to main content
Use the approval API when a local firewall policy returns REQUIRE_APPROVAL. The integration creates one request, polls its status for a bounded time, and executes the protected tool only after an APPROVED result. Both endpoints require a stable X-Lynx-Client-ID header. Lynx uses it with clientRequestId to make retries idempotent and to prevent another SDK instance from reading the request.

​
Create a request

POST /openapi/v1/firewall-approvals requires events:write.
timeoutMs must be between 1 second and 24 hours. Keep clientRequestId stable when retrying the same protected tool call. Do not reuse it for a different call. The API returns 201 with the current request state:

​
Poll the result

GET /openapi/v1/firewall-approvals/{approvalId} requires policies:read. Send the same X-Lynx-Client-ID used to create the request.
Possible statuses are:
  • PENDING: wait before polling again.
  • APPROVED: execute the exact protected call associated with inputHash.
  • REJECTED: do not execute the tool.
  • EXPIRED: do not execute the tool.
Use a fixed or jittered polling interval of at least one second and stop at the local deadline. Network errors, timeouts, invalid responses, and unexpected statuses must never allow the tool to run implicitly.
  1. Evaluate the active firewall policy locally.
  2. Create an approval request only for REQUIRE_APPROVAL.
  3. Preserve the request ID and clientRequestId across retries.
  4. Poll until approved, rejected, expired, or the local deadline is reached.
  5. Before execution, verify the tool name and input hash still match.
  6. Record the approval result in the same run and session.
Tool arguments and approval reasons may contain sensitive data. Send a deterministic hash instead of raw tool input, mask secrets in the reason, and never log the API key or approval credentials.