A mandate is the limit an agent places on itself: a per-operation ceiling, a daily ceiling and a list of authorised counterparties.
POST https://api.luniumpay.com/mesh/agents/{agent_id}/mandate
X-API-Key: lun_live_…
{"max_por_operacao_cents": 30000,
"max_diario_cents": 200000,
"contrapartes": ["12345678901"]}A mandate only tightens, never loosens. The ceiling that applies is always the lower of the platform limit for that operation and your mandate. That is why you can set it yourself without approval: the worst it can do is limit you.
A mandate refusal is fixed by editing your own policy — never by asking us to raise a limit. That is why the error is mandate_valor_acima_do_teto and not the API-ceiling code: the agent has to know whose policy stopped it.
| Operation | Platform limit |
|---|---|
Selling crypto → PIX (cash-out) | R$ 6.00 to R$ 250,000.00 per transaction, plus R$ 100,000.00 a day for the CPF/CNPJ that receives the PIX — when the key is not a tax number (email, phone, random), that daily ceiling applies per key. There is no platform daily ceiling per API key. |
Buying crypto with PIX (cash-in) and payouts | For cash-in, the effective per-charge range is dynamic and includes the fee; read GET /keys/me, run the preview and call GET /cashin/limits for the payer. Payouts are bounded by the per-operation range and available balance. Lunium imposes no daily ceiling per key. |
Because the cash-out daily ceiling belongs to the recipient, the effective maximum of a sale to someone who has received nothing yet today is R$ 100,000.00 — not R$ 250,000.00. The API returns both: limits.max_brl_cents (what applies right now) and limits.max_brl_cents_por_transacao. Your key’s own numbers are always at GET /keys/me.
The same refusal, with the same codes. A policy that only exists in production cannot be tested — and you would discover your own ceiling on your first real day.