> ## 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. # List saved Venmo and PayPal recipients (free) > Lists the Venmo or PayPal recipients this account has paid before, so you can resolve a name your human said ("send $20 to Jane") into the `handle` that `GET /send-payment` takes as its `recipient_id`. Free — only the payout itself is a paid action. Two different ids are in play. Each entry's `recipient_id` is an opaque saved-entry id: pass it to `POST` and `DELETE /payment-recipients`. Its `handle` is the phone number or email you actually pay: pass that as `recipient_id` to `GET /send-payment`. Passing the saved-entry id to `GET /send-payment` does not send to the saved person. Use `total_sent` and `last_sent_timestamp` to disambiguate similar names, and confirm with your human rather than guessing between two entries. Requires a Bearer token from `/auth` or `/get-card`. ## OpenAPI ````yaml /api-reference/openapi.json get /payment-recipients openapi: 3.1.0 info: title: Laso Finance x402 API version: 1.0.0 x-docs-revision: b5a8125aefd7 x-docs-manifest: https://laso.finance/.well-known/docs-version.json 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. 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). All cards are intended for the caller's own use. ## 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: /payment-recipients: get: summary: List saved Venmo and PayPal recipients (free) description: >- Lists the Venmo or PayPal recipients this account has paid before, so you can resolve a name your human said ("send $20 to Jane") into the `handle` that `GET /send-payment` takes as its `recipient_id`. Free — only the payout itself is a paid action. Two different ids are in play. Each entry's `recipient_id` is an opaque saved-entry id: pass it to `POST` and `DELETE /payment-recipients`. Its `handle` is the phone number or email you actually pay: pass that as `recipient_id` to `GET /send-payment`. Passing the saved-entry id to `GET /send-payment` does not send to the saved person. Use `total_sent` and `last_sent_timestamp` to disambiguate similar names, and confirm with your human rather than guessing between two entries. Requires a Bearer token from `/auth` or `/get-card`. operationId: listPaymentRecipients parameters: - name: platform in: query required: true description: Payment platform whose saved recipients to list. schema: type: string enum: - venmo - paypal - name: include_archived in: query required: false description: Include archived entries. Defaults to false. schema: type: string enum: - 'true' - 'false' responses: '200': description: The saved recipients for that platform. content: application/json: schema: type: object properties: user_id: type: string platform: type: string enum: - venmo - paypal recipients: type: array items: type: object properties: recipient_id: type: string description: >- Opaque id of this saved entry (for example `aQ3xK9mZpL2vB7nR4tYw`). Pass it as `recipient_id` to `POST` and `DELETE /payment-recipients`. It is not what `GET /send-payment` takes; use `handle` there. handle: type: string description: >- What to pay them at: a 10-digit phone number for Venmo, an email address for PayPal. Pass this as `recipient_id` to `GET /send-payment`. name: type: string description: The recipient's own name on the platform. display_name: type: string description: >- The label the account owner chose. Prefer it when confirming a payment back to a human. status: type: string total_sent: type: number description: >- Total dollars sent to this recipient from this account. send_count: type: integer last_sent_timestamp: type: integer description: Milliseconds since the epoch. security: - BearerAuth: [] components: 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.