> ## Documentation Index > Fetch the complete documentation index at: https://docs.laso.finance/llms.txt > Use this file to discover all available pages before exploring further. # Send USDC or any token from the managed wallet > Moves USDC out of the managed wallet to any Solana address, or to any USDC address on Base. Laso signs on your behalf. To send any other asset the wallet holds on Solana (USDT, SOL, any SPL or Token-2022 token), pass its mint as `mint`, or `native` for SOL; `getAgentWallet` lists them under `tokens`. Other assets go to Solana addresses only. Their `amount` is in the token's own units, and the send is valued at the token's market price for your spend limits; a token with no price cannot be sent by an agent (swap it to USDC with `agentWalletSwap`, or ask your human). If the recipient has no account for the token yet, creating one costs a small rent fee charged in USDC on top, so the wallet needs that much USDC. It draws on the whole balance: if the Solana side is short, the difference is pulled back from Base first (usually about 15 seconds). To send to Base, set `destinationNetwork` to `base` and pass a `0x` address. The managed wallet is a Solana wallet, so Laso bridges the USDC over CCTP and it lands as native USDC on Base, usually within a minute. `txHash` is the Solana transaction out of the managed wallet, not the Base delivery. The minimum is \$1. The recipient receives the amount less a 0.01% bridge fee. If the bridge fails, nothing is burned and the amount is credited to your Laso account balance instead. Every send you make, on either network, counts against the account's spend limits: it must be under the per-payment limit (see `getAgentSpendLimit`) and fit in what is left of the rolling 24-hour limit, which payments, sends, and withdrawals all draw on. A send over either is refused with `failed-precondition` before anything is signed. Do not split it into smaller sends to get under a limit; tell your human. Takes an address, and deliberately **not** an address-book name: a rename between your human asking and you sending would move money somewhere they did not intend. When you resolve a name via `listAddressBook`, say the address back to them before sending. A Firebase callable. Callables wrap the request in `{"data": ...}` and the reply in `{"result": ...}`. Send the `id_token` from `/auth` as a Bearer token. Free. ## OpenAPI ````yaml /api-reference/openapi.json post /agentWalletTransfer openapi: 3.1.0 info: title: Laso Finance x402 API version: 1.0.0 x-docs-revision: 2c96f69d4fc3 x-docs-manifest: https://laso.finance/.well-known/docs-version.json termsOfService: https://laso.finance/agent-terms.md contact: email: agents+support@laso.finance x-guidance: >- Laso Finance is a payment-gated (x402) API that lets an AI agent spend USDC on real-world financial products: prepaid cards (U.S. and international), gift cards, push-to-card transfers to USD/EUR/GBP debit cards, and Venmo/PayPal payouts. Payment: every paid route is an x402 v2 endpoint. Call it with no payment header to receive a 402 challenge listing the accepted networks, then replay with a signed USDC payment. Both Base (eip155:8453) and Solana (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) are accepted on every paid route; the caller picks either chain. Identity: `GET /auth` is free and identity-only. Prove wallet ownership with a `SIGN-IN-WITH-X` (CAIP-122) header to receive a Firebase id_token, then send that token as a Bearer credential to the authenticated read routes (`get-card-data`, `get-account-balance`, `get-kyc-status`, etc.). Paid routes also return fresh auth credentials in their response, so a payment is never required just to obtain a token. Recommended flow: (1) `GET /auth` to establish identity, (2) call a paid route (e.g. `GET /get-card`) to purchase a product, paying USDC on Base or Solana, (3) poll the authenticated read routes with the returned Bearer token to fetch the resulting card/transfer details. Reloadable card setup: the account holder links the card issuer once. Check `GET /get-card-issuer-status`; if it is `not_started`, call `POST /start-card-issuer-link` so the card issuer sends the account holder a one-time code, have the HUMAN read it from their own inbox and enter it in your interface (never read their email yourself), then `POST /verify-card-issuer-link` with the code and `consent_accepted: true`. Linking requires Laso identity verification (`kyc_required` returns a `kyc_url` for the human). Then fund with `GET /fund-card-balance` and create cards with `POST /create-reloadable-card`. Full machine-readable instructions live at https://laso.finance/SKILL.md. description: >- Payment-gated API for Laso Finance. All paywalled routes use the x402 protocol — the caller includes a USDC payment header on Base (eip155:8453) or Solana (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) and the server verifies payment before processing. Free routes require no payment header. The same 402 also carries an MPP (Machine Payments Protocol) challenge in WWW-Authenticate; an MPP client pays with USDC on Base by replaying with `Authorization: Payment ...`, and routes, prices, and responses are identical. ## Getting started To set up a wallet for making x402 payments, choose a provider: - **Locus** (default): https://paywithlocus.com/SKILL.md - **Sponge**: https://wallet.paysponge.com/skill.md — automatic x402 service discovery - **Ampersend**: https://www.ampersend.ai/getting-started.md — self-custody on Base or Solana with dual-approval spending limits. Laso Finance is a default skill, so no manual endpoint registration is needed. ## How x402 works 1. Call a paywalled endpoint without a payment header → receive a `402 Payment Required` response containing payment details (price, recipient address, network). 2. Construct an x402 payment header using the details from the 402 response. 3. Replay the request with the payment header → the server verifies payment and processes the request. ## Authentication flow `GET /auth` is free: callers prove wallet ownership by sending a `SIGN-IN-WITH-X` header (CAIP-122 wallet signature). Paywalled routes (`/get-card`, `/order-gift-card`, `/get-push-to-card`, `/order-intl-card`) also return fresh auth credentials in their responses, so a payment is never required just to obtain a token. Most routes return auth credentials (`id_token`, `refresh_token`, `expires_in`). Use the `id_token` as a Bearer token to call authenticated Laso Finance endpoints like `/get-card-data`. When the `id_token` expires, use `POST /auth` with `grant_type: refresh_token` to get a new one. ## Important notes The `/get-card` USA prepaid card endpoint is U.S. only — issued in USD, usable at U.S.-based merchants only, and physical goods must ship to a U.S. address. For non-U.S. merchants or non-USD currencies, use `GET /order-intl-card` instead (international prepaid card, admin-fulfilled within 24 hours). Agents act for a principal (a person 18+ or a business entity) under the [Agent Terms](https://laso.finance/agent-terms.md): every action is treated as the principal's own, and cards may be used for the principal's personal or business purchases. ## Rate limits Every response carries the request budget so you can pace yourself without probing for a limit: | Header | Meaning | | --- | --- | | `RateLimit-Limit` | Requests permitted per window | | `RateLimit-Remaining` | Requests still available | | `RateLimit-Reset` | Seconds until the window rolls over | | `RateLimit-Policy` | The policy these numbers describe, as `limit;w=seconds` | The same values are repeated as `X-RateLimit-*` for clients that only parse that spelling. Most routes advertise the service-wide ceiling. `POST /signup` enforces its own per-IP budget on top of it and overwrites these headers with its own numbers. `POST /refresh-card-data` is limited per card rather than per caller, so its headers keep the service-wide values and the per-card budget is reported only on rejection. Every rejection is a `429` carrying `Retry-After` in seconds and a matching `retry_after_seconds` field in the body, computed from the limit that actually rejected the request. Wait that long and retry once. Do not retry in a tight loop. ## API versioning Every response carries the contract version in an `X-Laso-Api-Version` header, and `GET /version` returns the same value as `api_version` alongside the policy below in machine-readable form. It is distinct from `X-Laso-Docs-Version`, which tracks the prose and moves whenever the documentation changes. | Change | What happens to `api_version` | | --- | --- | | New route, new optional request field, new response field | Unchanged. Tolerate unknown response fields. | | Breaking change | Ships under a new `api_version`. | A route being retired is marked `deprecated` in this description and answers with a `Deprecation: true` response header, plus a `Link` header with `rel="successor-version"` pointing at its replacement. Once a removal date is set it is published in a `Sunset` header (RFC 9745 / RFC 8594). There is no blanket notice period: the `Sunset` date on each deprecated route is the commitment. For step-by-step instructions, read https://laso.finance/SKILL.md servers: - url: https://laso.finance description: Production security: [] paths: /agentWalletTransfer: post: tags: - Agent Wallet summary: Send USDC or any token from the managed wallet description: >- Moves USDC out of the managed wallet to any Solana address, or to any USDC address on Base. Laso signs on your behalf. To send any other asset the wallet holds on Solana (USDT, SOL, any SPL or Token-2022 token), pass its mint as `mint`, or `native` for SOL; `getAgentWallet` lists them under `tokens`. Other assets go to Solana addresses only. Their `amount` is in the token's own units, and the send is valued at the token's market price for your spend limits; a token with no price cannot be sent by an agent (swap it to USDC with `agentWalletSwap`, or ask your human). If the recipient has no account for the token yet, creating one costs a small rent fee charged in USDC on top, so the wallet needs that much USDC. It draws on the whole balance: if the Solana side is short, the difference is pulled back from Base first (usually about 15 seconds). To send to Base, set `destinationNetwork` to `base` and pass a `0x` address. The managed wallet is a Solana wallet, so Laso bridges the USDC over CCTP and it lands as native USDC on Base, usually within a minute. `txHash` is the Solana transaction out of the managed wallet, not the Base delivery. The minimum is \$1. The recipient receives the amount less a 0.01% bridge fee. If the bridge fails, nothing is burned and the amount is credited to your Laso account balance instead. Every send you make, on either network, counts against the account's spend limits: it must be under the per-payment limit (see `getAgentSpendLimit`) and fit in what is left of the rolling 24-hour limit, which payments, sends, and withdrawals all draw on. A send over either is refused with `failed-precondition` before anything is signed. Do not split it into smaller sends to get under a limit; tell your human. Takes an address, and deliberately **not** an address-book name: a rename between your human asking and you sending would move money somewhere they did not intend. When you resolve a name via `listAddressBook`, say the address back to them before sending. A Firebase callable. Callables wrap the request in `{"data": ...}` and the reply in `{"result": ...}`. Send the `id_token` from `/auth` as a Bearer token. Free. operationId: agentWalletTransfer requestBody: required: true content: application/json: schema: type: object required: - data properties: data: type: object required: - userId - destinationAddress - amount properties: userId: type: string description: The Laso user id (the `usr_...` value from /auth). example: usr_7aff81763cae58c936aa6de67dd5a95e destinationAddress: type: string description: >- The recipient's address: a Solana address, or a `0x` address when `destinationNetwork` is `base`. example: 7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU destinationNetwork: type: string enum: - solana - base default: solana description: >- The chain `destinationAddress` is on. `base` is delivered by bridging over CCTP. amount: type: string description: >- Decimal string in the asset's own units (USDC unless `mint` is set), not atomic units. example: '5.50' mint: type: string description: >- The asset to send: an SPL token mint address, or `native` for SOL. Omit for USDC. Solana destinations only. example: Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB responses: '200': description: >- The `transferId`, `txHash`, `destinationAddress`, and `destinationNetwork`. content: application/json: schema: type: object properties: result: type: object headers: X-Laso-Api-Version: $ref: '#/components/headers/X-Laso-Api-Version' '400': description: A required field is missing or invalid. headers: X-Laso-Api-Version: $ref: '#/components/headers/X-Laso-Api-Version' '401': description: Missing, invalid, or expired Bearer token. headers: X-Laso-Api-Version: $ref: '#/components/headers/X-Laso-Api-Version' security: - BearerAuth: [] components: headers: X-Laso-Api-Version: description: >- The version of the API contract that produced this response, the same value `GET /version` returns as `api_version`. It moves only on a breaking change, so an agent can pin against it and tolerate unknown response fields without rechecking the docs. Distinct from `X-Laso-Docs-Version`, which tracks the prose. Present on every response once the service has read its version beacon; absent, rather than a placeholder, during the cold-start window before that read completes. schema: type: string example: 1.0.0 securitySchemes: BearerAuth: type: apiKey in: header name: Authorization description: >- Firebase ID token from `/auth` or any paid route, sent as a Bearer token: `Authorization: Bearer ` (the `Bearer ` prefix is required). ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.