The Agents API must be enabled for your platform, and spending pools are enabled per platform on top of it; until they are, the spending pool endpoints answer
403. To enable them, book a demo or reach out to your Lightspark contact.How a pool decides
Every agent payment checks the pool: sends (including Lightning), bank payouts, and card authorizations. A payment must fit both the agent’s own policy and its pool.- Payment type. A payment whose type is not in
allowedPaymentTypesis refused. - Limits. A payment that would take the pool over
limitAmount,perTransactionLimit,dailyLimitormonthlyLimitis refused. - Approval. A payment above the pool’s
approvalThresholdwaits for the customer’s approval, even when the agent’s own policy would execute it at once. Card authorizations are never held for approval.
AGENT_POLICY_DENIED and details.policyDenialReason set to POOL_LIMIT_EXCEEDED or POOL_PAYMENT_TYPE_NOT_ALLOWED; a refused card authorization is declined.
Payments in flight hold their amount against the pool until they complete or fail, so concurrent payments cannot together exceed it.
Payment types
Limit types
dailyLimit (per UTC day) and monthlyLimit (per UTC calendar month) are optional caps on top of limitAmount. perTransactionLimit caps a single payment.
Create a pool
POST /spending-pools with platform credentials. customerId, name, limitType, limitAmount and allowedPaymentTypes are required; period is required with RECURRING and rejected with TOTAL. currency defaults to USD.
201 Created
usage.remaining is the least room left under limitAmount, dailyLimit and monthlyLimit, never below zero, counting payments still in flight. Here it is 100000 because the daily cap is the tightest.
requiresAdminApproval is stored for your platform: set it when your product requires an administrator, rather than the agent’s own user, to approve the pool’s payments that need approval. Grid does not act on it.
Idempotent creation
Idempotency-Key is optional; send one so a retry cannot create a second pool. Keys are scoped to the customer.
- A retry with a key already used returns the pool the first request created, with
200instead of201. - The retry is compared with the pool as it is now. Reusing a key with a different name, currency, limit type, period, limit amount, per-transaction limit, approval threshold, daily or monthly limit, allowed payment types or
requiresAdminApproval, after the pool was changed, or for a pool that was archived, is rejected with409. - The same key on another customer creates a separate pool.
Assign agents
Put an agent in a pool when you create it (spendingPoolId on POST /agents), or move it later:
"spendingPoolId": null to take the agent out of its pool. The pool must belong to the agent’s customer, and the agent’s policy must be in the pool’s currency.
Read, change and archive
A change applies to payments decided after it. Lowering a limit below what is already spent refuses further payments; it never reverses one. Changing
limitType to RECURRING requires period, and changing it to TOTAL removes period. An archived pool takes no agents, cannot be changed (409), and is still returned by GET.
Next steps
- Policies & permissions: each agent’s own limits
- Approvals & audit: what happens to a payment above the pool’s threshold