Caps on what one
account can spend

Reserve credits before an expensive call, then commit what it actually cost.

Decision trace

How it works

1. Set the caps

   Account, device, network and API-key budgets in your own units: credits, cents or tokens.

2. Reserve first

   Call reserve before inference. Start the call only when allowed is true.

3. Commit or release

   Send the actual cost, or release the hold. Reservations expire after five minutes.

API

One endpoint, three operations. Keep the secret server-side.

POST https://nolgard.com/v1/spend
Content-Type: application/json

{
  "secret": "SITE_SECRET",
  "op": "reserve",
  "accountId": "user_42",
  "cost": 20
}

// Example response
{
  "allowed": false,
  "remaining": { "account": 10 },
  "reason": "account_budget"
}

Limits

• Account and device budgets run on the UTC day. Network and API-key budgets run on the UTC hour. A budget applies only when its identifier is in the request.
• Device spend uses the visitor and fingerprint hashes from that account's last verification. A reservation matching both hashes counts once.
• A reservation holds budget for five minutes, then expires. Commit or release before that; remaining balances include pending reservations.
• Exactly reaching a cap is allowed; exceeding it is denied. A committed cost above the estimate is recorded in full, so later calls are blocked.
• A blank cap means no cap. Zero blocks every positive spend. Reasons are account_budget, device_budget, network_budget and key_budget.
• More than 120 spend calls per minute per site return 429. Treat transport errors as a denial.
• A cap bounds the damage; it does not identify the spender. Link the accounts first, then size the grant.

Related

• Usage abuse
• Trial grants
• Repeat accounts