DEV Community: CAI

Payment Intents and Hosted Actions: The Checkout Flow Between Intent and Settlement

CAI — Fri, 14 Aug 2026 06:34:36 +0000

Payment Intents and Hosted Actions: The Checkout Flow Between Intent and Settlement

A SaaS developer adds checkout to their product. A customer clicks "buy." The payment clears. The developer has never written a line of crypto code, and the customer never connected a wallet. This is the design target for the @cai.com checkout flow. The API behind it is a three-layer system: a payment intent that tracks state, a hosted action that replaces wallet signatures with a browser click, and a polling loop that turns that click into settlement.

The Intent

Every payment starts with an intent. The GET /payment-intent-status endpoint is the read side of a state machine. You pass an intent id, and the response tells you where the payment is in its lifecycle. The intent model is partial-live in the current API, the system honors gap_id fields in responses and evolves as checkout scenarios expand, but the state transitions are already stable enough to build production flows around.

GET /payment-intent-status?id=int_abc123

Returns one of: pending, awaiting_user_confirmation, confirmed, completed, or failed. The transition from pending to awaiting_user_confirmation happens when the system receives a valid payment creation that needs the user to authorize it. The transition from confirmed to completed happens after the on-chain settlement reaches the required confirmation depth.

This state machine is what separates a checkout flow from a raw transfer. A raw transfer (POST /wallet-custodial-transfer) is fire-and-forget. You either get a tx hash or an error. An intent allows the system to hold state at each step, pause for user action, and resume automatically.

The Hosted Action

The hosted action link is the mechanism that bridges the gap between an API-driven agent and a human user who needs to confirm a payment. The endpoint is POST /create-hosted-action with a structured JSON body. The critical field is action_type. For payments, you pass deposit or a specific payment-related action type.

POST /create-hosted-action
Content-Type: application/json

{
  "action_type": "deposit",
  "amount_usd": 50,
  "chain": "ETH",
  "token": "usdc",
  "local_part": "alice"
}

The response returns a URL:

{
  "ok": true,
  "url": "https://cai.com/act/a1b2c3d4e5f6",
  "expires_at": "2026-08-14T07:00:00Z"
}

This URL serves a single-tap confirmation page. The user opens it, sees the amount, the destination, and a confirm button. No wallet extension. No gas fee in their browser. No seed phrase. They tap confirm, and the system moves the intent from awaiting_user_confirmation to confirmed.

The hosted action is the product insight that makes agent-initiated payments work in practice. An agent can create an intent, push a confirmation URL to the user's dashboard or email, and wait. The agent never handles the private key. The user never sees an opaque transaction request. Both sides of the trade get the abstraction they need.

The Polling Loop

Once the intent reaches confirmed, the agent polls for settlement. The polling endpoint is the same GET /payment-intent-status, now returning completed with a tx_hash.

GET /payment-intent-status?id=int_abc123

{
  "ok": true,
  "id": "int_abc123",
  "status": "completed",
  "tx_hash": "0x7a8b9c0d1e2f...",
  "chain": "ETH",
  "confirmations": 12,
  "settled_at": "2026-08-14T06:32:00Z"
}

The polling cadence depends on the chain. EVM chains settle in seconds to a couple of minutes. BSC and Polygon are faster. Tron is comparable to EVM. The intent response includes confirmations and a minConfirmations threshold so the agent knows when settlement is considered final.

For agents that need asynchronous notification instead of polling, the POST /transfer-notify-register endpoint accepts an optional webhook_url parameter. When the transfer settles, the system calls the webhook with the tx hash and confirmation count. This is the right pattern for high-volume checkout flows where polling every 5 seconds on 10,000 active intents would be wasteful.

The Full Flow

Putting the three layers together, an end-to-end checkout looks like this:

The merchant's backend calls POST /wallet-custodial-transfer (or creates a marketplace_order) to initiate payment. The response includes an intent id.
The backend creates a hosted action link via POST /create-hosted-action and returns the URL to the merchant's frontend.
The merchant redirects the customer to the hosted action page. The customer sees the amount, the merchant name, and a single confirm button.
The customer confirms. The backend receives a callback (or the frontend polls the intent status) showing confirmed.
The backend starts polling GET /payment-intent-status for the intent id, or waits for the webhook via POST /transfer-notify-register.
The intent transitions to completed. The backend records the tx hash and updates the order status.

The remarkable property of this flow is that step 3 never shows the customer a blockchain address, a gas fee estimate, or a transaction signing request. The checkout page looks exactly like a credit card checkout, except the settlement happens on-chain in stablecoins.

Guardrails Built Into the Flow

The hosted action flow includes two safety mechanisms that are important for production deployments.

First, the daily auto-limit is capped at $200 USD per account for agent-initiated payments. This limit applies at the API key level and resets daily. It prevents a compromised key from draining an account. Users who need higher limits can adjust them in the dashboard settings at cai.com/app.

Second, new recipients trigger a confirmation requirement. When the agent tries to send to an address or email that has never received a payment from this account before, the hosted action page shows a prominent warning about the new recipient. The user must explicitly confirm before the payment proceeds. This prevents a common attack pattern where an attacker substitutes their own address in a payment request.

The vault product (credential storage and rotation) covers the case where the agent's API key itself is compromised, but that is a separate track from the payment flow.

What This Enables

The intent-plus-hosted-action pattern is the foundation for several checkout models:

SaaS checkout. A subscription service generates a hosted action URL for each billing cycle. The user confirms once per period. No saved payment methods, no recurring charge disputes, no PCI scope.

Agent-to-agent settlement. Agent A needs to pay Agent B for a completed task. Agent A creates an intent and a hosted action link, which the user confirms. Both agents receive the settlement notification.

One-time storefront purchases. A digital goods storefront generates a hosted action link at checkout. The customer confirms in one tap. The store receives the payment in USDC within seconds.

Each of these models relies on the same three-layer architecture: create the intent, confirm via hosted action, poll until settlement. The abstraction is consistent whether the buyer is a human clicking a link or an agent calling an API.

The Polling Implementation

A practical polling implementation in Python looks like this:

import time, requests

def poll_payment_intent(intent_id, interval=5, timeout=300):
    deadline = time.time() + timeout
    while time.time() < deadline:
        resp = requests.get(
            f"https://api.cai.com/functions/v1/payment-intent-status?id={intent_id}",
            headers={"Authorization": f"Bearer {CAI_API_KEY}"}
        )
        data = resp.json()
        if data.get("status") in ("completed", "failed"):
            return data
        time.sleep(interval)
    raise TimeoutError(f"intent {intent_id} did not settle in {timeout}s")

For production, replace the synchronous loop with an async version or use the webhook path. The synchronous version is fine for low-volume checkout flows where the merchant processes a few hundred payments per day.

Status-Code Handling

Every endpoint in the flow follows the same error contract as the rest of the CAI API. 401 means the API key is invalid or expired. 403 means the key has insufficient scope (checkouts require pay or full scope). 429 means rate limiting. Back off and retry with exponential delay.

The intent-specific error codes include a gap_id field when the requested feature is still partial-live. Treat a gap_id response the same way you treat a 503: the feature exists but has limitations. Check the capabilities page at cai.com/capabilities for the current status of each feature.

Summary

The checkout flow built on payment intents and hosted actions solves a specific problem: how does an agent initiate a payment and get confirmation from a human user without sharing private keys, without asking the user to install a wallet, and without requiring the merchant to hold crypto? The answer is a stateful intent, a single-tap confirmation page, and a polling loop. The settlement happens in USDC on chain, but neither the buyer nor the seller touches the blockchain directly.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/capabilities.html

If You Tried the Checkout Flow and Hit a Bug

Comment below with:

What you ran the curl command, the create-hosted-action request, the intent id you polled.
What you expected the checkout to complete in one line, or the intent to transition to completed.
What you got the error message, the unexpected status, the timeout.
Your environment OS, Node or Python version, the MCP host (OpenClaw, Hermes, Codex, Cursor, or other), the CAI account tier.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

The @cai.com wallet API: balances, transfers, and the hosted-action flow

CAI — Wed, 12 Aug 2026 06:34:06 +0000

The @cai.com wallet API: balances, transfers, and the hosted-action flow

The wallet is the most-requested deep-dive from the four-pillars post. This post walks through the wallet API in detail: how to check balances, how to send a payment, how the user-confirmation pattern works, and the difference between custodial and self-custody.

The wallet in one sentence

A custodial multi-chain stablecoin wallet. Six chains. External wallets supported. MoonPay for fiat on-ramp. One custodial account for pay, transfer, convert, and bridge. No private key in chat.

Checking balances

The POST /get-wallet-balances endpoint returns the user's balances on one or more chains. The request is a JSON body with the chains and tokens to query.

curl -X POST https://api.cai.com/functions/v1/get-wallet-balances \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "chains": ["ETH", "polygon", "base"],
    "tokens": ["USDC", "USDT"]
  }'

The response includes the custodial wallet_binding addresses and any linked subwallets (read-only RPC for the external wallets the user has connected). Entries may include linked_subwallet: true for external wallet balances.

Common gotcha. If you query a chain the user hasn't deposited to yet, the response may include empty activity for that chain. That is expected behavior; the chain is supported, the indexer just hasn't seen any activity for this user yet.

Sending a payment

The POST /wallet-custodial-transfer endpoint initiates a payment. The response is a hosted-action URL. The user opens it, sees the recipient, the amount, and the chain, and taps once.

curl -X POST https://api.cai.com/functions/v1/wallet-custodial-transfer \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "to_address": "0x...",
    "amount": "10.00",
    "chain": "base",
    "token": "USDC"
  }'

The response:

{
  "transfer_id": "tx_...",
  "hosted_action_url": "https://cai.com/act/...",
  "expires_at": "2026-07-04T12:34:56Z"
}

The hosted-action URL is the user-confirmation pattern. The agent's API key is the authorization to call the CAI API on the user's behalf, but every transfer still needs the user's consent on the hosted-action page. The page is HTTPS, the tap is bound to a single transaction, and the URL expires in a short window. If the user does nothing, the payment does not go through.

Polling for the receipt

After the user taps once, the agent polls POST /transfer-status for the receipt.

curl -X POST https://api.cai.com/functions/v1/transfer-status \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"tx_hash": "0x..."}'

The response includes the on-chain tx hash when the transfer is confirmed. The agent can then show the receipt to the user.

Custodial vs self-custody

A custodial wallet means the user does not hold the private key. CAI holds it. The user gets a @cai.com address on each of six chains and can pay, transfer, convert, and bridge from any of them.

The difference from self-custody is the user-confirmation pattern. With self-custody, the user holds the key, signs each transaction, and is responsible for key management. With CAI's custodial wallet, the user holds the address and the user-confirmation tap; CAI holds the key and the signing infrastructure. The trade-off: CAI is a trusted third party for custody, but the user never has to paste a private key into an agent conversation.

External wallets are supported. Connect a MetaMask or a Ledger and the user keeps custody of their external assets while using CAI for the day-to-day. The external wallets appear as linked subwallets in the get-wallet-balances response.

Guardrails. The wallet has a $200/day auto-limit while CAI completes its security audit. New recipients and new devices always require confirmation. Think of it like cash in your pocket, perfect for daily spending. The vault product (multi-sig, time-locks) is coming for larger balances.

Top-up flows

To add funds to the wallet, the user can:

Send from an external wallet to the CAI custodial address on the chosen chain. The address is in the account dashboard.
Buy with MoonPay (fiat on-ramp). The account dashboard has a "Buy with MoonPay" button for each chain. MoonPay is a third-party service; regional availability and KYC requirements apply.
Use WeChat Pay (Planned). The WeChat Pay path is documented in cai.com/capabilities.html.

Each top-up flow eventually surfaces a hosted-action URL or a direct deposit link that the user completes on the chosen rail.

The wallet API is in cai.com/skill.md. The hosted-action flow is in cai.com/agent-payment.html. Apply at cai.com/app to get a wallet.

If you wired the wallet API and got an unexpected balance, a 5xx, or a missing `wallet_binding`

Comment below with:

What you ran -- the install command, the request, the MCP host config. Copy the actual command or request.
What you expected -- one sentence.
What you got -- the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment -- OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

Accepting payments with @cai.com: adding CAI checkout to your website or SaaS

CAI — Fri, 07 Aug 2026 06:29:06 +0000

Accepting payments with @cai.com: adding CAI checkout to your website or SaaS

A SaaS developer wants to accept payments without a merchant account, without chargebacks, and without asking customers to leave the checkout flow. A marketplace needs to collect payments from buyers and settle them to sellers. An AI agent needs to pay for API access programmatically. All three scenarios converge on the same problem: how does money move from payer to payee without a Plaid link, a Stripe onboarding, or a wallet address pasted in chat?

The @cai.com payment path covers two sides. The payer side (an agent paying from a CAI wallet, or a human tapping a hosted confirmation page) has been covered elsewhere. This post covers the merchant side: how to accept payments through CAI, what the API looks like, and where the honest limits are.

The two payment paths for merchants

CAI exposes two distinct receive paths, and the choice between them depends on how the customer pays.

Card (fiat) path: create_onramp_url returns a MoonPay-hosted URL where the customer pays by credit card. The funds land in the merchant's custodial EVM address as USDC (or the selected stablecoin). The merchant needs a CAI API key with pay or full scope.

Crypto path: create_deposit_link returns a CAI-hosted page (/act/<token>) showing the merchant's custodial addresses and QR codes. The customer sends crypto from their own wallet, and the deposit is indexed by CAI's activity feed.

The two paths are not interchangeable. Card works for customers who hold fiat. Crypto works for customers who hold USDC or other supported tokens. The merchant can offer both, or one, depending on their customer base.

The card path: create_onramp_url

The card path routes through MoonPay, which handles the fiat-to-crypto conversion, compliance checks, and card network processing. The merchant does not need a separate MoonPay account. The CAI API key is the only credential.

curl -X POST https://api.cai.com/functions/v1/create-onramp-url \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_usd": 50.00,
    "default_currency_code": "usdc_eth"
  }'

The response includes a url that the merchant redirects (or links) the customer to. The customer fills in their card details on MoonPay's hosted page, and the crypto lands in the merchant's custodial EVM address. The walletAddress is set server-side to the API key owner's custodial address, so the merchant does not need to specify a destination.

This is not a full payment processor. There is no cart abstraction, no order webhook, and no inventory management. The receipt is the MoonPay payment intent. The merchant confirms the payment by polling GET /payment-intent-status with the intent id, or by checking GET /wallet-activity-list for the incoming deposit.

Honest limit: MoonPay is a third-party provider. KYC requirements and regional availability apply. If MoonPay is unavailable for a given region (the API returns a 503 with GAP_ONRAMP_V1), the card path is unavailable for that customer. The honest fallback is the crypto deposit path.

The crypto path: create_deposit_link

For customers who already hold crypto, the deposit path is simpler. The merchant calls create_deposit_link and gets a CAI-hosted page.

curl -X POST https://api.cai.com/functions/v1/create-hosted-action \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "deposit"
  }'

The response is a url like https://cai.com/act/<token>. The merchant sends this URL to the customer. The customer opens it, sees the merchant's custodial addresses and QR codes for each chain, and sends crypto from their wallet. The deposit is indexed by CAI's activity feed and appears in GET /wallet-activity-list.

The deposit link is single-use and short-lived. The customer has a window to complete the deposit before the URL expires. The merchant can verify the deposit by polling GET /wallet-deposit-activity or GET /wallet-activity-list with the customer's name or reference.

For the crypto path, the merchant's custodial address is printed on the page. The customer sends from their own wallet, whether that is a CAI wallet, a MetaMask, a Ledger, or any other wallet that supports the target chain. The merchant does not need to know which wallet the customer uses.

The hosted action pattern

Both paths build on the same hosted action infrastructure. A hosted action URL is a CAI-hosted page that the payer or the customer opens in a browser. The page is HTTPS, the token is single-use, and the URL expires in a short window (typically 15 minutes). The page does not require the visitor to have a CAI account.

The hosted action is the user-confirmation surface. The payer sees the recipient, the amount, the chain, and taps once. The merchant sees the confirmation on the other side. The hosted action pattern is the same regardless of whether the flow is a deposit, a transfer, a login, or a wallet connect.

Confirming the payment

After the customer completes the payment (card or crypto), the merchant needs to confirm it landed. The confirmation tool depends on the payment method.

For card payments via MoonPay, the merchant polls GET /payment-intent-status with the payment intent id returned by the MoonPay flow. The response includes the status, the on-chain tx hash, and the confirmation count.

For crypto deposits, the merchant reads from the activity feed. GET /wallet-activity-list with direction: "in" and category: "deposit" returns the indexed deposits. If the deposit is not yet indexed, GET /wallet-deposit-activity or POST /wallet-deposit-confirm (with the tx hash) can surface it.

The distinction matters: card payments are confirmed through the payment intent API, not through the transfer status API. Crypto deposits are confirmed through the activity feed, not through the transfer status API. The transfer status API is for outbound custodial transfers, not for incoming deposits.

Guardrails and honest limits

CAI's receive path is designed for daily spending, not for treasury-sized balances. The $200/day auto-limit applies while the security audit completes. New recipients and new devices always require confirmation. Think of it like cash in your pocket, perfect for daily spending. The vault product (multi-sig, time-locks) is coming for larger balances.

The card path routes through MoonPay, which is a third-party provider. KYC and region limits apply. The crypto path is self-service: the customer sends from their wallet, and the merchant confirms on the activity feed.

The receive path is not a full payment processor. There is no cart, no order webhook, no inventory management, and no chargeback handling. The merchant handles the business logic of linking a payment to an order, and CAI handles the settlement.

If you tried the receive flow and hit a bug

Comment below with:

What you ran -- the API call, the hosted action URL, the curl command. Copy the actual request or the page URL.
What you expected -- one sentence.
What you got -- the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment -- OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

Setting up your agent's operating account: sign up at cai.com/app in 4 steps

CAI — Wed, 05 Aug 2026 06:36:57 +0000

Setting up your agent's operating account: sign up at cai.com/app in 4 steps

Your agent needs an operating account. Here is how to set one up in about 2 minutes, no card required, no private key to paste in chat.

The signup at cai.com/app is four steps. This post walks through each step with what the user sees, the actual fields, and what to do if a step fails. The steps below match the current cai.com/app page.

Step 1: Open cai.com/app and pick "Apply for @cai.com email"

Go to cai.com/app. The page has a single CTA: "Apply for @cai.com email." Click it. The first form field is your name.

Step 2: Enter your name

That's the only field on the first screen. There is no email field on this step; the email is collected next. Enter your name, click continue.

Step 3: Enter your existing email (this is where the 6-digit code goes)

CAI emails a 6-digit verification code to the address you provide. The code expires in 15 minutes. Enter the code into the form when it arrives.

If the code doesn't arrive:

Check spam. CAI's verification email is plain text with a 6-digit code; some providers sort it to spam if you haven't seen mail from cai.com before.
Wait 60 seconds. The email is sent immediately after you submit the form, but delivery can lag.
Click "Resend code" if the form has the option. A new code invalidates the old one.

If the code expires before you paste it: you can request a new one from the same form. The old code is invalidated; the new code has a fresh 15-minute window. There is no waiting for support.

Step 4: Enter the code, create a password, and you're done

Enter the 6-digit code, set a password (8+ characters, the form's complexity rules apply), and the signup completes. You are redirected to the account dashboard.

What you have at the end

After the four steps, you have:

A @cai.com email address. The SMTP/IMAP credentials are in the account dashboard if you want to use a desktop client.
A custodial multi-chain stablecoin wallet. The wallet is empty until you top it up; the four product pillars post covers the wallet in detail.
A user vault for site credentials. Empty until you add credentials; the same post covers the vault.
An API key for the agent you build or use. The key is in the account dashboard. Free tier covers read scopes; pay and full scopes may require verification.

The wallet has a $200/day auto-limit while CAI completes its security audit. New recipients and new devices always require confirmation. Think of it like cash in your pocket, perfect for daily spending. The vault product (multi-sig, time-locks) is coming for larger balances.

The signup takes about 2 minutes. No card is required. The email is free.

What to do next (technical reader)

If you are the technical reader, the one who reads dev.to to install things, the next step is npm i -g @cailab/mcp. The package drops the CAI MCP server into any MCP-compatible host: OpenClaw, Hermes, Codex, Cursor. The full quickstart is in cai.com/developers.html.

The contract an agent reads first is cai.com/skill.md. The companion artifact is the A2A Agent Card at cai.com/.well-known/agent.json.

How the agent logs in on your behalf

Once the account exists, the agent does not need your password. The CAI API exposes a hosted login flow: an agent calls POST /create-hosted-action with { "action_type": "login" } and gets back a url. That URL is a CAI-hosted page the user opens and confirms. The agent never types your credentials into chat, and the login link is one-time and short-lived.

That pattern is the same shape as the wallet's user-confirmation flow. The agent's API key is the authorization; the user's tap on a hosted page is the consent. You keep the password, and the agent keeps the ability to act on your behalf within the confirmations you allow.

Apply at cai.com/app. The signup is four steps, about 2 minutes, no card.

If you went through the signup flow described above and the code didn't arrive, expired too fast, or failed silently

Comment below with:

What you ran: the install command, the request, the MCP host config. Copy the actual command or request.
What you expected: one sentence.
What you got: the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment: OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

Pay Anyone by Their Name: How the @cai.com Directory Replaces Wallet Addresses

CAI — Fri, 31 Jul 2026 07:04:16 +0000

Sending a friend 20 USDC should not require copying a hex string from a chat app, checking the chain, and hoping the network matches. The @cai.com directory replaces wallet addresses with handles. Type the name, pick the handle, and the money moves.

This post covers the @cai.com address directory, how it resolves handles to wallets, and how person-to-person payments work without the user ever seeing a hex string.

The directory

The @cai.com directory maps every registered user to their custodial wallet addresses across six chains. When you sign up at cai.com/app, you get a handle like alice@cai.com and a wallet address on each supported chain. The directory stores the mapping.

The directory is not a blockchain itself. It is a lookup table that CAI maintains. The agent that needs to pay someone calls resolve-transfer-recipient with the recipient's email or handle, and gets back the canonical address on the requested chain.

The API call is straightforward:

curl -sS https://api.cai.com/functions/v1/resolve-transfer-recipient \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"chain": "BASE", "to_email": "friend@cai.com"}'

Response:

{
  "canonical_email": "friend@cai.com",
  "to_address": "0x..."
}

How payments work through the directory

Once the address is resolved, the agent initiates the transfer. The user confirms on a hosted-action page, and CAI executes the custodial transfer on the requested chain.

curl -sS https://api.cai.com/functions/v1/wallet-custodial-transfer \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "BASE",
    "token": "usdc",
    "amount": "20.00",
    "to_email": "friend@cai.com"
  }'

Notice the to_email field. The agent never touches a wallet address. It resolves the handle, then passes the handle back to the transfer endpoint. CAI handles the address resolution internally on the second call.

The public surface

The directory also has a public facing side. The cai.com/.well-known/agent.json file is the A2A Agent Card that lets other agents discover how to interact with CAI. The cai.com/capabilities.html page lists which features are live, which are in beta, and which carry gap IDs.

For the @cai.com address directory specifically:

Live (per capabilities.html): The directory is operational. All registered users are discoverable by their @cai.com handle.
Chain support: ETH, BASE, POLYGON, SOLANA, ARBITRUM, and OPTIMISM.
Gap ID: GAP_RESOLVE_V1 — signals that the resolution is live but may not cover every edge case (e.g., unregistered handles return a clear error, not a silent fail).

What this means for agents

An agent that needs to pay someone does not need to ask for a wallet address. It asks for the person's @cai.com handle. The agent resolves it, checks the balance, and initiates the transfer. The user confirms with one tap.

This is the same flow whether the agent is paying a freelancer, settling a split bill, or sending a recurring payment to a landlord. The directory abstracts the chain complexity. The agent works with names, not addresses.

The end-to-end

A complete payment flow through the directory:

Agent calls get-identity to confirm the user has a CAI account.
Agent asks the user for the recipient's @cai.com handle.
Agent calls resolve-transfer-recipient with the handle and the preferred chain.
Agent calls get-wallet-balances to confirm sufficient funds.
Agent calls wallet-custodial-transfer with the recipient's handle.
User confirms on the hosted-action page.
Agent confirms the payment landed via wallet-activity-list.

Every step works with the handle. The agent never sees a private key, never copies a hex address, and never asks which network the recipient is on.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

If you tried this flow and hit a bug, comment below with the command you ran, what you expected, and what you got. Bug reports get replied to within 24 hours.

How AI Agents Pay for APIs: x402, Payment Mandates, and the Agent Operating Account

CAI — Wed, 29 Jul 2026 09:51:45 +0000

How AI Agents Pay for APIs: x402, Payment Mandates, and the Agent Operating Account

The HTTP 402 status code has been reserved for "Payment Required" since 1998. For most of the web's history, it sat unused. But AI agents making API calls autonomously are finally giving it real traffic.

When an agent hits a paid API endpoint, the question shifts from "can it pay?" to "how does it pay without waking a human for every dollar?" That breaks into two parts: a protocol for agent-to-API payment (x402) and a delegation mechanism (payment mandates) that lets agents spend within user-defined limits without asking permission each time.

The x402 flow

The x402 protocol is straightforward. An agent calls an API endpoint. The API responds with HTTP 402, including a payment challenge in the response body. The challenge specifies the recipient address, amount, chain, and token. The agent forwards this challenge to a payer service, which checks the user's balance and executes the transfer.

CAI's implementation uses three endpoints.

First, POST /x402-payment-prepare takes the challenge from the API and checks whether the user has sufficient balance and whether an active mandate covers this merchant. It returns an attempt_id and a requires_user_confirm flag. When the user has set up a payment mandate for this domain, the flag is false and the agent can proceed.

Second, the agent calls POST /x402-payment-execute with the attempt_id and user_confirmed: true (or skips confirm when the mandate covers it). CAI executes the custodial transfer on the requested chain and returns a tx_hash as proof.

Third, the agent re-requests the paid API resource, attaching the tx_hash or x402_retry_hint from CAI's response. The API verifies the on-chain payment and serves the resource.

The retry is the agent's responsibility. CAI returns the proof of payment. The agent presents it to the seller.

Payment mandates: spending limits for autonomous agents

The mandate system is the more interesting piece. A payment mandate is a user-created permission that lets an agent spend up to certain limits on a specific merchant domain without asking for confirmation every time.

The flow starts with POST /payment-mandate-create. The user specifies the merchant_domain, a max_amount_per_payment_usd, a daily_cap_usd, optional allowed_resource_patterns, and an expires_in_hours value. The user approves the mandate through CAI's hosted verification page. Once active, the agent can call x402_payment_prepare for any charge on that domain, and the response sets requires_user_confirm: false as long as the charge stays within the mandate's limits.

The user can revoke the mandate at any time with POST /payment-mandate-revoke or inspect active mandates with GET /payment-mandate-status.

This follows the same pattern as the AP2 (Authorization Protocol for Payments) concept, but CAI's implementation is a CAI-native version. The system enforces spending caps per payment and per day, and the domain pattern matching limits which API endpoints the mandate covers.

Where the agent gets its wallet

Before any of this works, the agent needs a wallet to pay from. CAI's model is a custodial multi-chain wallet accessed via API key. The agent calls GET /get-identity to confirm the account exists, then POST /get-wallet-balances to check balances on the relevant chain.

If the balance is insufficient, the agent can generate a deposit link with POST /create-hosted-action (with action_type: "deposit") or use the fiat on-ramp via MoonPay (third-party KYC applies). The agent does not handle private keys. It calls the CAI API, and CAI executes the custodial transfer.

The full sequence is documented in the skill.md contract at https://api.cai.com/functions/v1, which is the single source of truth for all endpoints, scopes, and gap IDs.

The MCP path

For agents that use the Model Context Protocol, the @cailab/mcp npm package provides a stdio transport that exposes the same set of tools. The agent sets CAI_API_KEY as an environment variable and the MCP server handles the authentication and routing. The same x402 endpoints, mandate tools, and wallet operations are available through the MCP interface.

Early access guardrails

Since this is early access, CAI applies a $200 per day automatic spending limit. New recipients and new devices need user confirmation before the first transfer. The vault product for storing third-party site credentials is also available, which lets agents store and retrieve login credentials for platforms they interact with.

The honest label

The capabilities page at cai.com/capabilities.html marks x402 as Live and payment mandates as Live. Both carry gap IDs (GAP_X402_V1, GAP_PAYMENT_MANDATE_V1) that signal the implementation is operational but may not cover every edge case. The gap IDs are part of the API response, so agents can check them and adjust their behavior accordingly.

WeChat Pay is listed as Planned. Bridge and cross-chain transfers are Live (with GAP_BRIDGE_V1). The fiat on-ramp via MoonPay is Live with third-party KYC limits.

What this means for agent developers

Agent-to-API payment is no longer a design problem you need to solve from scratch. The x402 protocol gives you a standard way to handle HTTP 402 challenges. The mandate system lets agents operate autonomously within user-defined limits. The custodial wallet model means the agent never touches a private key.

The API contract lives at cai.com/skill.md. The MCP package is on npm. The capabilities matrix is at cai.com/capabilities.html. The agent calls get_identity, checks balances, and pays when it needs to.

The 402 status code has been waiting for a use case since 1998. AI agents might be the one that finally makes it stick.

Build an AI Agent That Reads Invoices and Pays Them: A CAI Tutorial

CAI — Fri, 24 Jul 2026 06:35:45 +0000

Build an AI Agent That Reads Invoices and Pays Them: A CAI Tutorial

Most AI agents today can reason, plan, and call APIs. But give one a PDF invoice and ask it to pay the bill, and it stops cold. The agent can't read your email to find the invoice. It can't check its wallet balance. It has no wallet at all.

This tutorial walks through building an agent that does the full loop: read an invoice from email, check the balance, and pay the bill. All via CAI's MCP API, no external wallet or email provider needed.

Step 1: Install the CAI MCP Server

The CAI MCP server exposes email, wallet, vault, and identity tools as standard MCP tools. Install it with npm:

npm i -g @cailab/mcp

Then configure the MCP host. In your Claude Desktop config, Cursor MCP settings, or Hermes agent config:

{
  "mcpServers": {
    "cai": {
      "command": "npx",
      "args": ["-y", "@cailab/mcp"],
      "env": {
        "CAI_API_KEY": "cai_..."
      }
    }
  }
}

Get your API key at https://cai.com/app with at least read scope for identity and balance checks, and pay or full scope for transfers.

Step 2: Verify the Agent Identity

Every CAI API call starts with identity verification. The first call returns the user's @cai.com email, linked wallet addresses, and account status:

curl -sS https://api.cai.com/functions/v1/get-identity \
  -H "Authorization: Bearer ***"

The response includes linked_wallets with chain addresses and a wallet_binding object. This is the agent's on-chain identity.

Step 3: Read the Inbox for Invoices

The CAI email product gives every user a @cai.com address. The mail-chat endpoint lets the agent ask natural-language questions about recent mail:

curl -sS https://api.cai.com/functions/v1/mail-chat \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"message": "Show me the most recent invoice or payment request from the last 7 days"}'

For structured extraction, use mail-summarize-actions:

curl -sS https://api.cai.com/functions/v1/mail-summarize-actions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json"

This returns a structured summary with suggested actions, including copyable codes and openable URLs from the email content.

Step 4: Check the Wallet Balance

Before paying, the agent checks the wallet on the relevant chain:

curl -sS https://api.cai.com/functions/v1/get-wallet-balances \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"chains": ["ETH", "BASE", "POLYGON"]}'

The response shows balances for native tokens plus USDC, USDT, and DAI on each chain. If the balance is short, the agent can mint a deposit link:

curl -sS https://api.cai.com/functions/v1/create-hosted-action \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"action_type": "deposit"}'

CAI's $200/day auto-limit protects against overspend, and every new recipient triggers a confirmation step before funds move.

Step 5: Resolve the Payee and Transfer

The agent resolves the recipient's @cai.com address to a wallet address:

curl -sS https://api.cai.com/functions/v1/resolve-transfer-recipient \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"chain": "ETH", "to_email": "vendor@cai.com"}'

The response returns canonical_email and to_address. The agent presents the full details to the user: recipient, amount, token, chain, and the irreversible nature of the action. Once confirmed:

curl -sS https://api.cai.com/functions/v1/wallet-custodial-transfer \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "ETH",
    "token": "usdc",
    "amount": "49.99",
    "to_email": "vendor@cai.com"
  }'

The agent then confirms the payment with wallet-activity-list:

curl -sS https://api.cai.com/functions/v1/wallet-activity-list \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"limit": 5, "direction": "out"}'

Step 6: Store Recurring Payment Credentials

For recurring bills, the vault stores site credentials so the agent can log in and download invoices on future cycles:

curl -sS https://api.cai.com/functions/v1/user-site-credentials \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "origin_url": "https://vendor.com",
    "kind": "password",
    "payload": {"username": "user@cai.com", "password": "..."}
  }'

The vault product is under active development and will expand to support automated credential rotation and session refresh.

The Full Agent Loop

Putting it all together, the agent's bill-pay flow looks like this:

User says "pay the electric bill"
Agent calls mail-chat to find the latest invoice email
Agent extracts the amount and due date
Agent calls get-wallet-balances to confirm sufficient funds
Agent resolves the payee with resolve-transfer-recipient
Agent presents the details to the user for confirmation
User confirms, agent calls wallet-custodial-transfer
Agent confirms the payment landed via wallet-activity-list
Agent vaults the site credentials for next month

This loop is the same pattern whether the agent is paying an invoice, topping up an API credit account, or settling a marketplace order. The cash-in-pocket framing means the agent never needs a private key in chat, and every transfer is custodial, auditable, and reversible on the chain level.

If you tried this and hit a bug

Comment below with:

What you ran -- the install command, the request, the MCP host config. Copy the actual command or request.
What you expected -- one sentence.
What you got -- the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment -- OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

The four product pillars of @cai.com - email, wallet, vault, agent surface

CAI — Wed, 22 Jul 2026 07:37:22 +0000

The four product pillars of @cai.com - email, wallet, vault, agent surface

Four things come with a free @cai.com email. This post walks through each one in detail, with the actual API calls and the install commands. If you read the launch post first, this is the deep-dive; if you didn't, this stands alone.

1. The email itself

A real inbox at @cai.com. Send and receive mail like any other address. The signup gives you the address; the dashboard gives you the SMTP/IMAP credentials if you want to use a desktop client.

The mail surface is exposed to agents via the CAI API. An agent can read and summarize mail on your behalf (POST /mail-chat), send mail (POST /send-email), and fetch structured summaries (POST /mail-summarize-actions). Every read and every send is a scoped API call, gated on your API key and your confirmation pattern for outbound messages.

2. The custodial multi-chain stablecoin wallet

A custodial wallet means you do not hold the private key. CAI holds it. You get a @cai.com address on each of six chains, and can pay, transfer, convert, and bridge from any of them. External wallets are supported - connect a MetaMask or a Ledger and you keep custody of your external assets while using CAI for the day-to-day.

The wallet API (per cai.com/skill.md):

# Check balances on one or more chains
curl -X POST https://api.cai.com/functions/v1/get-wallet-balances \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"chains": ["base", "polygon"]}'

# Send a payment (returns a hosted-action URL for user confirmation)
curl -X POST https://api.cai.com/functions/v1/wallet-custodial-transfer \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "to_address": "0x...",
    "amount": "10.00",
    "chain": "base",
    "token": "USDC"
  }'

The response to wallet-custodial-transfer includes a hosted-action URL. The user opens it, taps once, and the payment goes through. The agent polls GET /transfer-status for the receipt.

The wallet is custodial. That word does a lot of work, and it matters. The user-confirmation pattern is the difference from self-custody: no private key in chat, no manual signature, one tap on a page CAI hosts.

$200/day auto-limit while CAI completes its security audit. New recipients and new devices always require confirmation. Think of it like cash in your pocket -- perfect for daily spending. The vault product (multi-sig, time-locks) is coming for larger balances.

3. The user vault for site credentials

The vault is for your site credentials - the logins and passwords you have scattered across a hundred sites. When the agent you build needs to log in to one of those sites, the agent retrieves the credential from the vault (with your explicit confirmation), uses it for the action, and you do not re-type the password.

The vault is not for the agent's API key. The agent's CAI_API_KEY is a separate secret, used by the agent to call CAI's API. Storing it in the vault is a circular dependency. The vault is for the third-party sites the agent logs in to on your behalf.

The vault API (per cai.com/skill.md §6.3):

# Save a site credential (user action)
curl -X POST https://api.cai.com/functions/v1/user-site-credentials \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "origin_url": "https://example.com",
    "kind": "password",
    "payload": {
      "username": "alice",
      "password": "..."
    }
  }'

# List saved credentials (metadata only, no decrypted payload)
curl -X GET https://api.cai.com/functions/v1/user-site-credentials \
  -H "Authorization: Bearer ***"

The vault entries are encrypted at rest, indexed by site, retrievable via the CAI API. You can revoke any vault entry from the account dashboard.

4. The agent surface

For the agent you build (or the agent you use), the surface is the MCP server, the contract, and the API.

The install:

npm i -g @cailab/mcp

The contract: cai.com/skill.md - the canonical source-of-truth, written in a format agents parse.

The discovery surface for other agents: cai.com/.well-known/agent.json - the A2A Agent Card.

The API: https://api.cai.com/functions/v1 - the HTTPS Edge API. The MCP server is a thin wrapper that makes the calls typed and convenient for the agent.

The MCP server drops into any MCP host: OpenClaw, Hermes, Codex, Cursor. Once installed, the agent's tool surface includes CAI. The agent's first call is GET /get-identity to confirm the user has a CAI account; if they don't, the agent can show them the signup URL.

The agent surface next

If you want the API surface, cai.com/skill.md is the canonical source. The signup flow at cai.com/app is four steps, about 2 minutes, no card.

Apply at cai.com/app. The npm package is on the npm registry. The contract is at cai.com/skill.md.

If you tried any of the four product pillars in this article

Comment below with:

What you ran - the install command, the request, the MCP host config. Copy the actual command or request.
What you expected - one sentence.
What you got - the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment - OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

What does the @cai.com wallet actually do? — six chains, external wallets, MoonPay

CAI — Fri, 10 Jul 2026 06:44:09 +0000

What does the @cai.com wallet actually do?

A custodial multi-chain stablecoin wallet comes with every @cai.com account. No separate signup, no additional KYC beyond the email verification. This post covers what the wallet is, what it supports, and how to use it.

Six chains, one custodial account

The wallet gives you a @cai.com address on each of six chains. You can pay, transfer, convert, and bridge from any of them without managing six separate private keys. The custodial model means CAI holds the key; you hold the address and the user-confirmation tap.

External wallets supported

Connect a MetaMask, a Ledger, or any external wallet. The external wallet appears as a linked subwallet in your balance view — you keep custody of your external assets while using the CAI wallet for day-to-day transfers.

Topping up

To add funds:

Send from an external wallet to your CAI custodial address on the chosen chain. The address is in the account dashboard.
Buy with MoonPay — fiat on-ramp via the account dashboard. Partial-live in some regions (KYC and region limits apply per cai.com/capabilities.html).
WeChat Pay — documented in cai.com/capabilities.html under the Payment options section.

The wallet API

For the technical reader, the wallet surface is available through the CAI API. Check balances:

curl -X POST https://api.cai.com/functions/v1/get-wallet-balances \\
  -H "Authorization: Bearer ***" \\
  -H "Content-Type: application/json" \\
  -d '{"chains": ["base", "polygon"]}'

Send a payment (returns a hosted-action URL for user confirmation):

curl -X POST https://api.cai.com/functions/v1/wallet-custodial-transfer \\
  -H "Authorization: Bearer ***" \\
  -H "Content-Type: application/json" \\
  -d '{
    "to_address": "0x...",
    "amount": "10.00",
    "chain": "base",
    "token": "USDC"
  }'

Every transfer needs the user's confirmation on a hosted-action page — one tap, no private key in chat.

The wallet API is documented in cai.com/skill.md. The dashboard is at cai.com/app.

If you tried any of the four product pillars in this article

Comment below with:

What you ran — the install command, the request, the MCP host config. Copy the actual command or request.
What you expected — one sentence.
What you got — the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment — OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

CAI.com — a custodial @cai.com email, multi-chain stablecoin wallet, and MCP-installable agent API

CAI — Sat, 04 Jul 2026 15:42:03 +0000

CAI.com — a custodial @cai.com email, multi-chain stablecoin wallet, and MCP-installable agent API

A custodial email, a stablecoin wallet, a credential vault, and an agent-ready API — all at one @cai.com address.

This post walks through what CAI is, what you get when you sign up, and how to wire the agent side into any MCP-compatible host.

What you get at cai.com/app

A free @cai.com email comes with four product surfaces, all under one account:

A real inbox at @cai.com. Send and receive mail like any other address. The signup gives you the address; the dashboard gives you the SMTP/IMAP credentials if you want to use a desktop client.
A custodial multi-chain stablecoin wallet. Built in. Six chains. External wallets supported. MoonPay for fiat on-ramp (partial-live, third-party KYC and region limits apply — see cai.com/capabilities.html).
A user vault for site credentials. Store website logins and passwords. The agent you build retrieves them when needed, with your explicit confirmation. The vault is for your site credentials, not the agent's API key.
An API key for the agent you build or use. Free tier covers read scopes; pay and full scopes may require verification. The key is in the account dashboard.

How the signup works

The signup at cai.com/app is four steps. About 2 minutes.

Go to cai.com/app. Pick "Apply for @cai.com email."
Enter your name. That's the only field on the first screen.
CAI emails a 6-digit verification code to the address you provide. The code expires in 15 minutes. The email has a one-time link, not the code — copy the code from the email and paste it into the form.
Enter the code, create a password, and you're done.

At the end you have:

A @cai.com email address.
A custodial multi-chain stablecoin wallet.
A user vault for site credentials.
An API key for the agent you build or use.

No card. The email is free.

The agent side (for the technical reader)

For the technical reader, the agent side is the reason to look at CAI. The install is one command:

npm i -g @cailab/mcp

The package is the MCP server — a thin wrapper around the CAI HTTPS Edge API at https://api.cai.com/functions/v1. It drops into MCP-compatible hosts including OpenClaw, Hermes, Codex, and Cursor (see cai.com/developers.html for the current host list). Once installed, the agent can call GET /get-identity, POST /get-wallet-balances, POST /wallet-custodial-transfer, and the rest of the CAI surface — without the user pasting a private key in chat.

The contract an agent reads first is cai.com/skill.md. It's the canonical source-of-truth for what CAI can do, written in a format agents parse. The companion artifact is the A2A Agent Card at cai.com/.well-known/agent.json — that's how agents discover CAI in agent-to-agent registries.

If you tried this and hit a bug

Comment below with:

What you ran — the install command, the request, the MCP host config. Copy the actual command or request.
What you expected — one sentence.
What you got — the error message, the empty response, the unexpected behavior. Paste it verbatim.
Your environment — OS, Node version, the MCP host (OpenClaw / Hermes / Codex / Cursor / other), the CAI account tier if relevant.

Every comment on this article gets read. Bug reports will be replied to within 24 hours. Friction points shape what we document next.

Documentation: cai.com/skill.md · cai.com/developers.html · cai.com/app to sign up.

DEV Community: CAI

Payment Intents and Hosted Actions: The Checkout Flow Between Intent and Settlement

Payment Intents and Hosted Actions: The Checkout Flow Between Intent and Settlement

The Intent

The Hosted Action

The Polling Loop

The Full Flow

Guardrails Built Into the Flow

What This Enables

The Polling Implementation

Status-Code Handling

Summary

If You Tried the Checkout Flow and Hit a Bug

The @cai.com wallet API: balances, transfers, and the hosted-action flow

The @cai.com wallet API: balances, transfers, and the hosted-action flow

The wallet in one sentence

Checking balances

Sending a payment

Polling for the receipt

Custodial vs self-custody

Top-up flows

If you wired the wallet API and got an unexpected balance, a 5xx, or a missing wallet_binding

Accepting payments with @cai.com: adding CAI checkout to your website or SaaS

Accepting payments with @cai.com: adding CAI checkout to your website or SaaS

The two payment paths for merchants

The card path: create_onramp_url

The crypto path: create_deposit_link

The hosted action pattern

Confirming the payment

Guardrails and honest limits

If you tried the receive flow and hit a bug

Setting up your agent's operating account: sign up at cai.com/app in 4 steps

Setting up your agent's operating account: sign up at cai.com/app in 4 steps

Step 1: Open cai.com/app and pick "Apply for @cai.com email"

Step 2: Enter your name

Step 3: Enter your existing email (this is where the 6-digit code goes)

Step 4: Enter the code, create a password, and you're done

What you have at the end

What to do next (technical reader)

How the agent logs in on your behalf

If you went through the signup flow described above and the code didn't arrive, expired too fast, or failed silently

Pay Anyone by Their Name: How the @cai.com Directory Replaces Wallet Addresses

The directory

How payments work through the directory

The public surface

What this means for agents

The end-to-end

How AI Agents Pay for APIs: x402, Payment Mandates, and the Agent Operating Account

How AI Agents Pay for APIs: x402, Payment Mandates, and the Agent Operating Account

The x402 flow

Payment mandates: spending limits for autonomous agents

Where the agent gets its wallet

The MCP path

Early access guardrails

The honest label

What this means for agent developers

Build an AI Agent That Reads Invoices and Pays Them: A CAI Tutorial

Build an AI Agent That Reads Invoices and Pays Them: A CAI Tutorial

Step 1: Install the CAI MCP Server

Step 2: Verify the Agent Identity

Step 3: Read the Inbox for Invoices

Step 4: Check the Wallet Balance

Step 5: Resolve the Payee and Transfer

Step 6: Store Recurring Payment Credentials

The Full Agent Loop

If you tried this and hit a bug

The four product pillars of @cai.com - email, wallet, vault, agent surface

The four product pillars of @cai.com - email, wallet, vault, agent surface

1. The email itself

2. The custodial multi-chain stablecoin wallet

3. The user vault for site credentials

4. The agent surface

The agent surface next

If you tried any of the four product pillars in this article

What does the @cai.com wallet actually do? — six chains, external wallets, MoonPay

What does the @cai.com wallet actually do?

Six chains, one custodial account

External wallets supported

Topping up

The wallet API

If you wired the wallet API and got an unexpected balance, a 5xx, or a missing `wallet_binding`