SIGNALS Documentation
API Reference

Batch Approvals

Select and approve structurally eligible requests while keeping each request independently verified and recorded.

Overview

Batch approval is available in the Approvals Inbox for pending requests that the server currently classifies as structurally eligible. It is a speed tool for a known set of decisions, not a financial risk score.

For a task-led walkthrough, see Batch-Approving Eligible Requests.

Eligibility

A selection checkbox appears only when all of these conditions are true:

  • the request is pending and has at least one pending assignment;
  • you can action every pending assignment on the request;
  • neither the request nor any pending assignment has passed its expiry;
  • the request has no active escalation recipient or overdue assignment;
  • the captured chain has exactly one non-skipped stage;
  • neither its event nor transition is a high-risk account operation (account.high_risk.*) or invoice write-off authorization (invoice.write_off.authorization);
  • when approvals.bulk_approve_value_cap is set, a numeric requested value in tenant base currency is present and at or below the cap.

The optional tenant cap is stored in base-currency minor units. With no cap, no value test applies. The REST bulk-approve endpoint applies the same rules, including the single-stage restriction. Amount-based refusal details are hidden without cost visibility.

Approve a batch

  1. Open /approvals and use Needs you, filters or search as needed.
  2. Select eligible rows or choose Select low-risk for the current page. Changing the filter or search clears the current selection.
  3. Choose Approve with the selected count. One submission accepts at most 100 distinct request IDs.

Before recording anything, the inbox verifies the complete selection again. If any selected request is no longer eligible at that point, it clears the selection and asks you to review the queue.

During the mutation, each request is locked and checked again in its own database transaction. Successful requests remain approved if a different request fails. The result reports the number approved and the number that could not be approved, and the batch action is retained in the audit history.

REST refusals

POST /api/v1/approvals/bulk-approve applies the same checks. Per-request refusal codes include approval_not_authorized, approval_not_pending, approval_expired, approval_escalated, approval_multi_stage, approval_excluded_type, approval_no_value, and approval_over_cap. Without cost visibility, an over-cap request returns approval_not_low_risk instead. Results retain the existing 200/207 response behaviour.

When a checkbox is absent

Open the request normally when it is expired, escalated, no longer pending, includes an assignment you cannot action, or otherwise needs individual attention. Delegation and operational controls remain available according to your permissions.