Infinite skill for AI assistants

​

The credential decides the tools

​

BYO org vs Infinite Connect (platform)

​

Organization-key tools

​

Agent-key tools

​

Core rules (always apply)

• Start read-only when the request is unspecified. When the user says “try it”, verify the connection, then read (get_agent, get_balance, list_payees, or list_accounts). Do not move money until the user gives the details and confirms.
• Confirm before money moves. Call create_transfer without confirm, show the user the returned summary (amount, currency, payee, rail), and call submit_transfer only after an explicit yes. Pass confirm: true only when the user already approved that exact payment.
• MCP amounts are exact decimal strings in the agent’s limit currency: "40.00", not 40, 4000, "$40", or "40.0001". If the user’s amount can’t be represented exactly, ask; never round for them. The REST API uses integer minor units ("4000" = $40.00); never mix the two.
• One operationId per payment, reused on every retry. Generate a UUID v4 once for a business event (for example, invoice SD-1042), keep it, and pass the same value if you retry. A new value creates a second payment.
• A denial is an answer, not an error to route around. submit_transfer returns { denial: { code, window, limit, used, remaining, attemptedAmount, currency } } — amounts are decimal strings like every other agent tool — with a hint. A per-transfer denial (window: "perTransaction") has no used / remaining; limit is the most one payment can be. Explain it to the user. Do not retry with a different payee, split the payment, or switch keys to get past a limit. When submit_transfer is denied for a limit, the draft stays DRAFT, moves no money, and doesn’t count toward limits; leave it and create a new draft if the user picks a smaller amount. A denied create_transfer with confirm: true saves nothing. On agent_paused / agent_revoked, stop.
• Do not claim Infinite is connected until a read-only call succeeds (get_organization_info). A config entry is not proof.
• Business verification is a human step. Send the start_verification link to the user; never collect identity documents or tax IDs in chat when a hosted link is available. In production, review takes hours to days.
• Prefer MCP tools. When no tool covers a step, use the REST API with the same key and check get_endpoint_schema first instead of guessing request shapes.
• Do not log full account numbers, keys, or tax IDs.

​

Talking to the user

• Say what you are doing in plain terms: “I’ll check your balance and budget, then draft the payment for you to approve.”
• Before anything moves, show the exact amount, payee, and rail, and ask.
• If something isn’t available (a rail, a currency, a capability the customer doesn’t have yet), say so and offer the supported path. Don’t overstate what the account can do.

​

Denial codes

​

Setup

​

If the tools don’t show up

1. Reload or restart the host so it picks up the new server (Claude Code: start a new session and run /mcp; Cursor: refresh MCP tools in Settings).
2. Call get_organization_info. Only a successful call proves the tools are usable.
3. 401 Unauthorized means the header didn’t arrive or the key is wrong or revoked; check the header, not the URL.
4. After a reload, never re-run a payment automatically. Confirm with the user first.

​

Journeys

​

Onboard a business

1. create_business_customer with the legal name, email, and country, and a new UUID v4 operationId. Keep the returned continuationToken.
2. request_capabilities for what they need (for example USD_BALANCE, USD_ACH_PAYOUT) before verification — a customer can only be updated while it’s DRAFT or NEED_ACTIONS.
3. For API KYB (host already has facts/files): search_industry_codes then update_business_details to save business fields without submitting; upload docs and finish with submit_customer_verification. Prefer start_verification when a human can complete hosted KYB.
4. Poll get_customer until ACTIVE, then get_capabilities until the ones you need are READY.
5. ensure_balance_account, then get_deposit_instructions so the user can fund it.

​

Add a payee draft (organization key, platform sessions)

​

Create a transfer draft (organization key, platform sessions)

​

Create an agent (organization key)

curl -X POST https://sandbox.api.infinite.dev/v1/agents \
  -H "Authorization: Bearer $INFINITE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "AP Agent",
    "customerId": "cus_…",
    "sourceAccountId": "vba_…",
    "allowedDestinationAccountIds": ["eba_…"],
    "limits": { "currency": "USD", "perTransaction": "30000", "perDay": "60000", "perMonth": "500000" }
  }'

​

Pay an invoice (agent key)

1. get_agent, get_balance, and list_payees to confirm budget, funds, and the payee.
2. create_transfer with the payee’s destinationAccountId, the exact decimal amount, a paymentReason (usually PAYMENT_FOR_GOODS_AND_SERVICES), a UUID v4 operationId you keep for this invoice, and the invoice number as reference. The reference is always kept on the transfer (reference in get_transfer) and sent to the payee on ACH, wire, SWIFT, and RTP (not on other rails); ACH allows only 10 letters/digits, so INV-77 goes out as INV77. The summary tells you exactly what the payee sees.
3. Show the returned summary and wait for approval.
4. submit_transfer. On success report the status (PENDING, then COMPLETED); on a denial, explain it using the table above.
5. wait_for_transfer to follow it to a final status (it returns timedOut: true if still in flight — call it again; never resubmit). Operators receive transfer.* webhooks, each carrying the agentId.

​

Check budget, balance, or status (agent key)

​

Related

• Agents: the model, limits, and webhooks
• MCP: server details and per-host configuration
• API reference and the OpenAPI spec