Skip to content

How it works

  1. POST /v1/users with email, phone_e164, and a password. nuez creates the account, a default API key for MCP use, and (in widget onboarding mode) an identity verification widget URL.
  2. Complete KYC through the widget URL.
  3. Receive your CVU once onboarding finishes β€” GET /v1/cvu or the get_cvu MCP tool.
  4. Fund your wallet by transferring to that CVU from any Argentine bank, Mercado Pago, or UalΓ‘.
  5. Generate additional API keys per agent if you want independent revocation β€” POST /v1/api-keys.

Until KYC (onboarding = "done") completes, the policy engine denies every payout with kyc_incomplete β€” see Policy engine.

Under the threshold β€” agent executes autonomously

Section titled β€œUnder the threshold β€” agent executes autonomously”
AGENT β†’ POST /v1/withdraws (or request_payout MCP tool)
β†’ policy.Evaluate() β†’ decision: allow
β†’ payout submitted to the bank rail
β†’ status: submitted
β†’ webhook: payout.requested, payout.submitted

No human involved. The payout attempt is created with decision: "allow" and executes immediately.

Over the threshold β€” WhatsApp or Telegram approval

Section titled β€œOver the threshold β€” WhatsApp or Telegram approval”
  1. Agent calls request_payout (MCP) or POST /v1/withdraws (REST) with an amount that trips one of the threshold rules.
  2. The policy engine returns require_approval and the payout attempt is created with status: "pending_approval" β€” the call returns immediately with an approval_id and expires_in (seconds), it does not block or long-poll.
  3. nuez sends a notification to the account owner via WhatsApp or Telegram, whichever channel is linked, with a 6-character challenge token and an amount/destination summary.
  4. The owner replies APPROVE:XXXXXX / REJECT:XXXXXX (or taps a button, which sends the same format). nuez resolves the approval and updates the payout attempt to approved or rejected.
  5. If approved, nuez submits the withdraw to the bank rail. A signed webhook (payout.approved, then payout.submitted/payout.confirmed) fires on your configured endpoint.
  6. If no response arrives within APPROVAL_EXPIRY_MINUTES (default 5 minutes), a background worker marks it expired and fires payout.expired.

There is no MCP tool or REST endpoint to approve a payout directly β€” approval only happens by replying to the WhatsApp/Telegram message. Poll GET /v1/withdraws/{id} or get_payout_status to check whether a pending payout has resolved, or just wait for the webhook.

Design principle: the human only appears when it matters. Below the threshold, full autonomy. Above it, approval via a channel the owner already has open.

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ AI Agent β”‚ Claude Desktop, Cursor, CLI, custom agent
β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚ POST /mcp (JSON-RPC) OR REST /v1/* (JWT)
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ nuez API (single :8080) β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Policy engine β”‚ KYC Β· amount Β· whitelist Β· absolute cap Β·
β”‚ β”‚ per-tx / daily / monthly limits
β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”
β”‚ β”‚
β–Ό β–Ό
Execute Pause + notify (WhatsApp/Telegram)
β”‚ β”‚
β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Bank rail β”‚ CVU/CBU/alias payout rail
β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
β–Ό
Signed webhook (X-Nuez-Signature) β†’ your endpoint

Cards, bill payments, and crypto off-ramp follow the same pattern β€” MCP tool or REST call β†’ store β†’ underlying rail β€” but bill payments and card issuance are gated by their own whitelist/balance checks rather than the payout policy engine. See Cards, Bill payments, and Crypto off-ramp.