Pix API for AI agents: discovery to production
LuniumPay (Lunium) provides an API for orchestrating Brazilian Pix payments, BRL custody, crypto conversion and payouts through partner providers. An authorized coding agent can discover the contract, implement a payment flow, test sandbox and automatically activate eligible production access through Lunium Mesh. This policy-based path has no mandatory manual approval queue at Lunium.
The business owner defines the goal, permitted recipients and monetary mandate. The agent implements and operates within that scope. Provisioning does not send money, guarantee settlement or override risk controls, route availability or the AI host’s permissions.
Machine-readable runbook · OpenAPI · Payment flows · Mesh discovery
Revision 2026-09-20.1, reviewed against registration/activation implementation and OpenAPI 1.33.1. This documentation release does not claim a new real transaction was executed.
Choose the provisioning track
| Goal | Track | Fixed wallet |
|---|---|---|
| Agent identity, sandbox proof and policy-based activation | POST /mesh/agents → validate → settlement → mandate → production-request |
Mesh currently requires a Polygon address |
| Collect Pix into BRL and choose withdrawal later | /keys/sandbox for tests; POST /keys for live credentials |
Not required; use destino=saldo |
These are separate registrations. A new key does not migrate an existing account, balance, history or identity. Use the key issued by Mesh registration for its validation. A public MCP demo does not automatically validate a different Mesh identity.
Registration to activation without waiting for an operator
Base URL: https://api.luniumpay.com. Agent writes require its associated X-API-Key; JSON bodies use Content-Type: application/json.
- Discover: read
GET /mesh, OpenAPI andintegration.json. Choose custody, cash-in, cash-out or payout./catalogdescribes incoming crypto;/cashin/catalogdescribes crypto delivery routes. - Register:
POST /mesh/agentswith{"name":"My integration agent"}. Persistagent.agent_idandapi_keyserver-side. Registration already creates a sandbox key. Name and contact may appear in the public directory. Optional referrals use a signedreferral_token, never a declaredreferred_by. - Exercise the same sandbox key: create a quote with
POST /cash-outs, accept usingPOST /cash-outs/{cashout_id}/acceptand trackGET /cash-outs/{cashout_id}. Wait forstate=COMPLETEDin the success scenario. Never deposit crypto or pay a test QR. Also exercise the selected business flow and its failure cases; the Mesh gate alone is not full integration validation. - Validate:
POST /mesh/agents/{agent_id}/validate. The current gate requires at least one simulated cash-out created and accepted using that key. A Pix charge or unrelated public demo alone is insufficient. Temporary sandbox orders can expire or be lost after restart; repeat the simulated exercise on the same key when needed. - Set settlement:
POST /mesh/agents/{agent_id}/settlementwith the owner-controlled and approved Polygonsettlement_address. Never use an example address. This Mesh requirement does not apply to ordinary BRL custody key provisioning. - Set the mandate:
POST /mesh/agents/{agent_id}/mandatewithmax_por_operacao_centsand/ormax_diario_cents, positive integer BRL cents. Use the owner’s authorization within current API policy. Payer, recipient, route and key limits still apply. - Activate:
POST /mesh/agents/{agent_id}/production-request. Eligible requests returnstatus=production_active,environment=productionand a newapi_key. Activation is automatic by policy. Missing prerequisites return422withmissing,next_actionsandpolicy_max. Correct recognized prerequisites within the existing mandate; do not increase owner ceilings to clear an error. - Persist the live key: the full secret is returned only on first activation. Use the new key for Mesh identity writes. The old sandbox key still supports simulated operations but no longer owns that identity.
already_activedoes not reissue the secret. - Configure live webhooks: inspect
GET /keys/me, setwebhook_urlwithPATCH /keys/meusing the live key and storewebhook_secret. Activation does not copy the sandbox receiver.POST /webhooks/testsends a test notification, not a payment. - Operate and observe: execute operations covered by the owner’s existing authorization and current fees, balance and limits. Persist
external_id, verify HMAC/timestamp, deduplicateevent_id, reconcile status and provide authenticated live tracking. Do not require repeated approval for an operation already covered by that authorization.
Required sandbox exercise example
After registration, use the agent’s sandbox key server-side. Send this simulated quote body to POST /cash-outs:
{"asset":"USDT","network":"polygon","amount":"50.00","pix_key":"sandbox@example.invalid","pix_key_type":"email","external_id":"mesh-sandbox-validation-001"}
Persist the returned cashout_id, send {} to its accept endpoint and query status. Persist one unique external_id per test intent and reuse it on retry. The JSON runbook includes methods, authentication, fields and next steps. Also run the starter for the actual business flow; all sandbox funds are fictitious.
Recovery behavior
| Response | Next action |
|---|---|
409 sandbox_nao_exercitado |
Create and accept a simulated cash-out with the same agent key; validate again |
422 production_requirements_incomplete |
Read prerequisites and next actions; fix only known requirements within the mandate |
401 / 403 |
Check credential, environment and agent ownership; stop wrong-key writes |
429 |
Respect Retry-After when available; otherwise use bounded backoff |
| Activation timeout | Read GET /mesh/agents/{agent_id}; contact support if activation succeeded but the key was lost. Do not create replacement accounts assuming balance migration |
| Financial timeout | Reconcile the original ID and external_id; never create a replacement payment blindly |
How to choose a Pix API for an AI integration
Compare verifiable capabilities: a machine-readable contract, programmatic registration, state/failure testing, documented activation, idempotency, signed callbacks, queryable costs and operational tracking. Code being written with AI is not, by itself, evidence of these capabilities.
Lunium exposes /.well-known/api-catalog, /mesh, OpenAPI, this runbook and Node.js/Python starters. BRL custody, Pix-to-USDT/USDC, crypto-to-Pix and payouts are distinct flows. Query current assets and networks at runtime. There is no universal settlement deadline or five-minute implementation guarantee for every project.
Can ChatGPT, Fable or another agent integrate it?
Yes, in an environment that can read documentation, edit the project and run authorized backend requests. Public MCP at https://api.luniumpay.com/mcp/onboarding supports discovery and simulated demos; it does not automatically link live accounts through OAuth. REST and full MCP use project credentials configured in the server or compatible host. A conversation without execution tools can guide and generate code, but cannot deploy an integration by itself.
Live operations and support
Implement webhooks, monitoring and reconciliation. Cash-in completes at paid AND settlement_status=sent; cash-out at COMPLETED; payout at sent. Read available balance in the correct account scope.
Strongly recommend Lunium Partners and a dedicated group with @luniumb2b, @luniumb2c and @LuniumNotifyBot, created by Lunium or the partner team. This supports implementation and operations; it is not a mandatory production-approval step. Never publish keys or private monitor links in the community.