Skip to main content
Tier 3 corporates configure approval rules in Dashboard → Settings → Approvals & alerts. Rules can depend on amount, currency, process and channel. API transactions are exempt until the corporate explicitly opts them in. The business owner retains dashboard control; an owner’s API key still follows API opt-in rules.
Signature required: Yes. Send X-Numero-Api-Key, X-Numero-Signature and X-Numero-Signature-Version: v2. Use the original operation’s scope: vas:write for VAS/global digital goods and transfers:write for transfers and wallet payments. An initiating endpoint can return PendingApproval instead of executing immediately. Save the original reference, then poll approval status. The response contains approvalStatus, requiredApprovals, approvalsCollected, minApproverLevel, expiresAt and executionReferences. When multiple rails share a reference, supply the matching rail query parameter; otherwise the status endpoint returns 409 rather than guessing. Examples include WALLET_PAYMENT, USD_CARD_FUND and GLOBAL_VAS. Approval votes are made by eligible active team members through the dashboard. The initiator cannot count as an independent approver. The polling endpoint does not cast votes. An approved request is released to its transaction workflow; it is not proof of settlement or product delivery. Use the returned execution references and original transaction status endpoint to establish the outcome. Rejected, expired or invalid requests must not be resubmitted blindly. Revoking an initiating API key prevents release of its pending requests. Approval request and decision emails are part of the workflow. Additional transaction alert email addresses are configured separately: adding an address grants no approval rights and does not send it authentication or transaction-confirmation codes. Neither email delivery nor a click in an email substitutes for the authenticated approval state. See Wallet payments and Global digital goods for each operation’s confirmation, expiry and retry rules.