Approvals

Maker-checker, and what your product can see of it.

Keys post directly. People do not: what a person asks for becomes an approval, and a different person decides it. This one workflow covers adjustments, reversals, freezes, limit changes, FX rates, fee schedules, named account changes, modules and new ledgers.

Nothing in this workflow can be done with an API key except reading. Proposing and deciding happen in the console. The exception is a loan write-off, which a key can ask for.

The rules

• The proposer never decides their own request.
• Above the tenant’s singleApproverMax, two different people must approve. Money in a currency other than the base currency always needs two.
• Above stepUpAbove, each approver must have just confirmed their identity.
• The change is applied in the same transaction as the final approval. If the ledger refuses it then, the request ends FAILED, with the reason in failureCode.

GET /v1/tenant shows both amounts, in minor units of the base currency.

Reading approvals

A key with read can follow a request.

curl "$PANOQORE_URL/v1/approvals/$APPROVAL" -H "Authorization: Bearer $PANOQORE_API_KEY"

{
  "id": "mdl_01M6F1DR4ZEDKS4T20ZDCVWP5E",
  "kind": "MODULES",
  "status": "APPROVED",
  "title": "Change account modules",
  "reason": "Switch on lending for the docs tenant",
  "approvalsRequired": 1,
  "createdAt": "2026-11-02T21:07:41.855224Z",
  "decidedAt": "2026-11-02T21:07:41.982021Z"
}

Status	Meaning
WAITING	Waiting on someone.
APPROVED	Approved and applied.
REJECTED	Refused.
WITHDRAWN	The proposer took it back.
FAILED	Approved, but the ledger refused to apply it.

GET /v1/approvals filters by kind and view, and subscribing to approval.* webhooks saves polling.