Agents

Early access. Agents are enabled per organization alongside per-key transfer policy — ask your account team. Until enabled, POST /v1/agents and key issuance return 403 agents_not_enabled; see Building blocks for the objects an agent is made of.

An agent (agt_) is a spending identity inside your organization. It is bound to one ACTIVE customer and one funding account, carries hard spend limits and an optional destination allowlist, and authenticates with its own key (sk_live_agent_ / sk_sandbox_agent_). Every transfer the key makes is attributed to the agent and checked against its limits at the network — not in your code.

Lifecycle

Create the agent — name, principal customer, source account, limits, allowlist
Issue a key — the secret is returned once; give it to the runtime
Pay — the runtime calls POST /v1/transfers with the agent key; onBehalfOf defaults to the agent’s customer
Watch — GET /v1/agents/{id}/spend and GET /v1/transfers?agentId=
Pause or revoke — PATCH status PAUSED stops new writes and keeps keys; DELETE revokes the agent and every key

customerId, sourceAccountId, and limits.currency are fixed at create — start a new agent to change them.

Create an agent

Amounts are in smallest units as strings (cents for USD). Limits must be in the source account’s currency.

import requests

response = requests.post(
    'https://api.infinite.dev/v1/agents',
    headers={
        'Authorization': 'Bearer sk_live_...',
        'Content-Type': 'application/json',
        'Idempotency-Key': '550e8400-e29b-41d4-a716-446655440000',
    },
    json={
        'name': 'Procurement Agent',
        'description': 'Buys supplies',
        'customerId': 'cus_abc123',
        'sourceAccountId': 'vba_agent_balance',
        'allowedDestinationAccountIds': ['eba_vendor456'],
        'limits': {
            'currency': 'USD',
            'perTransaction': '100000',
            'perDay': '500000',
            'perMonth': '1000000',
        },
    },
)
agent_id = response.json()['id']

const response = await fetch('https://api.infinite.dev/v1/agents', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
    'Idempotency-Key': '550e8400-e29b-41d4-a716-446655440000',
  },
  body: JSON.stringify({
    name: 'Procurement Agent',
    description: 'Buys supplies',
    customerId: 'cus_abc123',
    sourceAccountId: 'vba_agent_balance',
    allowedDestinationAccountIds: ['eba_vendor456'],
    limits: {
      currency: 'USD',
      perTransaction: '100000',
      perDay: '500000',
      perMonth: '1000000',
    },
  }),
});
const { id: agentId } = await response.json();

export INFINITE_API_KEY=sk_live_...
infinite api POST /v1/agents \
  --header 'Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000' \
  --body '{
  "name": "Procurement Agent",
  "description": "Buys supplies",
  "customerId": "cus_abc123",
  "sourceAccountId": "vba_agent_balance",
  "allowedDestinationAccountIds": ["eba_vendor456"],
  "limits": {
    "currency": "USD",
    "perTransaction": "100000",
    "perDay": "500000",
    "perMonth": "1000000"
  }
}'

Create an agent called "Procurement Agent" for buying supplies, paying from vba_agent_balance on behalf of cus_abc123, only to eba_vendor456, with a $1,000 per-transaction limit, $5,000 per day, and $10,000 per month.

# Agent management is an organization-key operation — run the CLI tab (or the console).

curl -X POST "https://api.infinite.dev/v1/agents" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -d '{
    "name": "Procurement Agent",
    "description": "Buys supplies",
    "customerId": "cus_abc123",
    "sourceAccountId": "vba_agent_balance",
    "allowedDestinationAccountIds": ["eba_vendor456"],
    "limits": {
      "currency": "USD",
      "perTransaction": "100000",
      "perDay": "500000",
      "perMonth": "1000000"
    }
  }'

The response is the Agent object with status: ACTIVE.

Issue a key

Creating an agent returns an ID, not a credential. Issue a key from a console session or an unconstrained organization key (one with no transfer policy); an agent key cannot mint keys.

key = requests.post(
    f'https://api.infinite.dev/v1/agents/{agent_id}/keys',
    headers={'Authorization': 'Bearer sk_live_...', 'Content-Type': 'application/json'},
    json={'name': 'procurement-runtime'},
).json()
print(key['secret'])  # sk_live_agent_... — shown once

const key = await fetch(`https://api.infinite.dev/v1/agents/${agentId}/keys`, {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ name: 'procurement-runtime' }),
}).then((r) => r.json());
console.log(key.secret); // sk_live_agent_... — shown once

export INFINITE_API_KEY=sk_live_...
infinite api POST /v1/agents/agt_abc123/keys \
  --body '{"name": "procurement-runtime"}'

Issue a key for agent agt_abc123 named "procurement-runtime".

# Agent management is an organization-key operation — run the CLI tab (or the console).

curl -X POST "https://api.infinite.dev/v1/agents/agt_abc123/keys" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"name": "procurement-runtime"}'

secret is returned only in this response. Store it in your secrets manager; afterwards GET /v1/agents/{id}/keys shows only keyHint. Agent keys have fixed scopes: transfers:read, transfers:write, accounts:read, customers:read, plus read access to their own agent and spend. Connect an assistant to the MCP server with an agent key and it gets payment tools — list_payees, get_balance, get_quote, create_transfer (draft), submit_transfer, get_agent — bound by the same limits. Reads are scoped: the key sees only its own agent, its own transfers, and its principal customer’s record and accounts. They cannot manage agents or keys, and — because they carry the agent’s pins — cannot create payout batches or debit any other account.

Pay as the agent

The runtime uses the agent key on POST /v1/transfers. onBehalfOf must be the agent’s customer and source.accountId the agent’s source account; anything else is denied before routing.

requests.post(
    'https://api.infinite.dev/v1/transfers',
    headers={
        'Authorization': 'Bearer sk_live_agent_...',
        'Content-Type': 'application/json',
        'Idempotency-Key': '7c9e6679-7425-40de-944b-e07fc1f90ae7',
    },
    json={
        'onBehalfOf': 'cus_abc123',
        'amount': {'currency': 'USD', 'rawValue': '12500'},
        'source': {'currency': 'USD', 'paymentRail': 'BALANCE', 'accountId': 'vba_agent_balance'},
        'destination': {'currency': 'USD', 'paymentRail': 'ACH', 'accountId': 'eba_vendor456'},
        'paymentReason': 'PAYMENT_FOR_GOODS_AND_SERVICES',
        'confirm': True,
    },
)

await fetch('https://api.infinite.dev/v1/transfers', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_agent_...',
    'Content-Type': 'application/json',
    'Idempotency-Key': '7c9e6679-7425-40de-944b-e07fc1f90ae7',
  },
  body: JSON.stringify({
    onBehalfOf: 'cus_abc123',
    amount: { currency: 'USD', rawValue: '12500' },
    source: { currency: 'USD', paymentRail: 'BALANCE', accountId: 'vba_agent_balance' },
    destination: { currency: 'USD', paymentRail: 'ACH', accountId: 'eba_vendor456' },
    paymentReason: 'PAYMENT_FOR_GOODS_AND_SERVICES',
    confirm: true,
  }),
});

export INFINITE_API_KEY=sk_live_agent_...
infinite transfers create \
  --customer cus_abc123 \
  --amount 12500 \
  --amount-currency USD \
  --source-currency USD \
  --source-rail BALANCE \
  --source-account vba_agent_balance \
  --dest-account eba_vendor456 \
  --dest-currency USD \
  --dest-rail ACH \
  --reason PAYMENT_FOR_GOODS_AND_SERVICES \
  --confirm

Pay $125.00 to eba_vendor456 by ACH for goods and services, and submit it.

# Connected with the agent key: the assistant calls create_transfer, shows you the draft, then submit_transfer.

curl -X POST "https://api.infinite.dev/v1/transfers" \
  -H "Authorization: Bearer sk_live_agent_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 7c9e6679-7425-40de-944b-e07fc1f90ae7" \
  -d '{
    "onBehalfOf": "cus_abc123",
    "amount": { "currency": "USD", "rawValue": "12500" },
    "source": { "currency": "USD", "paymentRail": "BALANCE", "accountId": "vba_agent_balance" },
    "destination": { "currency": "USD", "paymentRail": "ACH", "accountId": "eba_vendor456" },
    "paymentReason": "PAYMENT_FOR_GOODS_AND_SERVICES",
    "confirm": true
  }'

The transfer response includes agentId. Denials are 403 with a machine-readable code:

Code	Meaning
`agent_limit_exceeded`	Per-transaction, daily, or monthly cap hit. Body includes `window`, `limit`, `used`, `attemptedAmount`, `currency`.
`agent_approval_required`	The agent asks for approval over its limits (`overLimitAction: REQUEST_APPROVAL`) and this submit went over one — the draft now waits for you. Same body as `agent_limit_exceeded`. Also returned when the agent resubmits a draft that is waiting or was declined.
`agent_limit_currency_mismatch`	Transfer source currency differs from `limits.currency`. Body includes `attemptedAmount`, `currency`.
`agent_paused` / `agent_revoked`	Agent status blocks new submissions
`agent_transfer_mismatch`	An agent tried to submit a draft created by a different agent

Customer, source-account, and destination-allowlist mismatches return the same 403 messages as per-key transfer policy — the agent’s key carries those pins.

Limits

Limit	Window	Counts
`perTransaction`	each transfer	the transfer’s `amount`
`perDay`	UTC calendar day	submitted transfers — `DRAFT`, `FAILED`, `CANCELLED`, `REVERSED` excluded
`perMonth`	UTC calendar month	same

Limits are enforced when a transfer leaves DRAFT (confirm: true at create, or submit), in the same transaction as the status change, so two concurrent submits cannot both pass. GET /v1/agents/{id}/spend returns used, remaining, and resetsAt per window.

Owner approval

By default a payment over a limit is denied. Set overLimitAction: REQUEST_APPROVAL on the agent (at create or with PATCH /v1/agents/{id}) and it is sent to you instead:

The agent submits a draft over a limit. It gets 403 agent_approval_required; the draft stays DRAFT with agentApprovalStatus: PENDING, and agent.approval_requested fires with the limit it went over.
You find waiting payments with GET /v1/transfers?agentApprovalStatus=PENDING.
You decide with POST /v1/transfers/{id}/agent-approval and { "decision": "APPROVE" } or { "decision": "DECLINE", "reason": "…" } from the console or an organization key. Agent keys cannot decide.
- While approval is pending, the draft can’t be edited, so the owner approves exactly what the agent asked for.
- Approve submits the draft. Only the spend limits are skipped — a paused or revoked agent, a currency mismatch, or a payee removed from the allowlist still refuse it. The payment counts toward the agent’s spend.
- Decline cancels the draft.
agent.approval_resolved fires with the decision, and the agent sees agentApprovalStatus change on the transfer.

Approval applies to submitted drafts. A create with confirm: true over a limit is always denied, since there is no draft to hold — have the agent create a draft and submit it.

Attribution

Transfers made with an agent key carry agentId in the transfer response and in every transfer.* webhook payload, and can be filtered with GET /v1/transfers?agentId=. A DRAFT created by an agent key keeps that attribution — and that agent’s limits — even if a console user submits it later.

Webhooks

Event	When
`agent.created`	agent created
`agent.updated`	limits, allowlist, name/description, or status (pause / resume) changed
`agent.limit_reached`	a transfer was refused by the agent’s limits — payload includes `denial` with `code`, `window`, `limit`, `used`, `attemptedAmount`
`agent.approval_requested`	a payment over a limit is waiting for owner approval — payload includes `transferId` and `denial`
`agent.approval_resolved`	the owner approved or declined it — payload includes `transferId` and `decision`
`agent.revoked`	agent revoked; all keys dead

Subscribe in the console under Developer → Webhooks. See Webhooks.

Building blocks

An agent sits on the same REST surface as any other caller: a KYB-verified customer, accounts issued to that customer, and transfers that screen on every instruction. The Agent resource binds them together and enforces the limits at the network. Know your agent (KYA) is the discipline. Bind the agent to a verified business, give it a funded account, restrict it to screened payees, and keep a webhook record of every state change. From MCP, an organization key gets the onboarding tools (create_business_customer, start_verification, …) and an agent key gets the payment tools (create_transfer, submit_transfer, …). See Paying with an agent key.

Setting one up

Create a business customer for the principal, or reuse one already ACTIVE
Issue that customer a dedicated account — fund only what the agent should spend
Register payees as counterparties and external accounts, and wait for them to leave IN_REVIEW
Create the agent with that customer, account, limits, and payee allowlist, then issue its key
Subscribe to webhooks for agent.* and transfer.*, and poll the transfer when you need authoritative status

What an agent needs

Mapped to the object you call. Everything in this table is live.

Need	Use today
Wallet account	Accounts, balance accounts, and treasury wallets on an `ACTIVE` customer
Pay, request, accept	`POST /v1/transfers` plus deposit instructions; hosted pay page from the console
Transfer	Transfers, fixed routes, quotes, FX
Credit	Liquidity facility for organization treasury (USDC on Solana)
Connect	Customers + verification links + `onBehalfOf` on transfers
Bill	`developerFeeFixed` / `developerFeePercent` on transfers and fixed routes (not on provider-balance onramp sweep targets)
Identity	Verification, customers, and counterparties for KYC / KYB
Observability	Webhooks, `GET /v1/transfers/{id}`, MCP logs
Compliance	Customer compliance, RFIs, verification status

Roadmap. The Agent resource above is early access. Per-agent credit, payment Links, card issuing (preview), usage-based billing, a public invoice API, and instruction-audit export (GET /v1/internal/transfers/{id}/instruction-audit) are in early access or beta. Ask your account team for access; nothing on this page depends on them.

Wallet account

A dedicated account on a verified customer. The available balance caps what that account can send — a transfer cannot debit more than it holds. Organization API keys can still reach other customers and accounts unless you constrain the caller.

Job	Object	How
Hold USD	Balance account (`vba_`, `holdsBalance: true`)	`POST /v1/balance-accounts` after `USD_BALANCE` is `READY` on capabilities
Hold stablecoins	Provider balance (`pba_`)	`POST /v1/balance-accounts/stablecoin`
Crypto treasury	Infinite wallet (`inw_`)	Auto-provisioned when the customer is approved. List with `GET /v1/accounts?type=INFINITE_WALLET`
Standing receive address	Fixed-route mailbox	`POST /v1/fixed-routes/virtual-bank-accounts` or `/virtual-wallets`

Treasury wallets have no public create endpoint. Model one agent as one customer, or one dedicated account on a shared customer. See Accounts and Balance accounts.

Pay, request, and accept

Pay, request, and accept are the same money-movement objects with different directions. Pay — the agent sends. Create a transfer from a balance account to a screened destination. Source rail must be BALANCE when paying from a held USD balance:

import requests

response = requests.post(
    'https://api.infinite.dev/v1/transfers',
    headers={
        'Authorization': 'Bearer sk_live_...',
        'Content-Type': 'application/json',
        'Idempotency-Key': '550e8400-e29b-41d4-a716-446655440000',
    },
    json={
        'onBehalfOf': 'cus_abc123',
        'amount': {
            'currency': 'USD',
            'rawValue': '12500',
        },
        'source': {
            'currency': 'USD',
            'paymentRail': 'BALANCE',
            'accountId': 'vba_agent_balance',
        },
        'destination': {
            'currency': 'USD',
            'paymentRail': 'ACH',
            'accountId': 'eba_vendor456',
        },
        'counterpartyId': 'cp_vendor456',
        'paymentReason': 'PAYMENT_FOR_GOODS_AND_SERVICES',
        'confirm': True,
    },
)

const response = await fetch('https://api.infinite.dev/v1/transfers', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer sk_live_...',
    'Content-Type': 'application/json',
    'Idempotency-Key': '550e8400-e29b-41d4-a716-446655440000',
  },
  body: JSON.stringify({
    onBehalfOf: 'cus_abc123',
    amount: {
      currency: 'USD',
      rawValue: '12500',
    },
    source: {
      currency: 'USD',
      paymentRail: 'BALANCE',
      accountId: 'vba_agent_balance',
    },
    destination: {
      currency: 'USD',
      paymentRail: 'ACH',
      accountId: 'eba_vendor456',
    },
    counterpartyId: 'cp_vendor456',
    paymentReason: 'PAYMENT_FOR_GOODS_AND_SERVICES',
    confirm: true,
  }),
});

export INFINITE_API_KEY=sk_live_...
infinite api POST /v1/transfers \
  --header 'Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000' \
  --body '{
  "onBehalfOf": "cus_abc123",
  "amount": {
    "currency": "USD",
    "rawValue": "12500"
  },
  "source": {
    "currency": "USD",
    "paymentRail": "BALANCE",
    "accountId": "vba_agent_balance"
  },
  "destination": {
    "currency": "USD",
    "paymentRail": "ACH",
    "accountId": "eba_vendor456"
  },
  "counterpartyId": "cp_vendor456",
  "paymentReason": "PAYMENT_FOR_GOODS_AND_SERVICES",
  "confirm": true
}'

Pay $125.00 to eba_vendor456 by ACH for goods and services. Show me the draft first, then submit it when I approve.

# Runs on MCP when the session uses an agent key (create_transfer → submit_transfer). With an organization key, run the CLI tab.

curl -X POST "https://api.infinite.dev/v1/transfers" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000" \
  -d '{
    "onBehalfOf": "cus_abc123",
    "amount": {
      "currency": "USD",
      "rawValue": "12500"
    },
    "source": {
      "currency": "USD",
      "paymentRail": "BALANCE",
      "accountId": "vba_agent_balance"
    },
    "destination": {
      "currency": "USD",
      "paymentRail": "ACH",
      "accountId": "eba_vendor456"
    },
    "counterpartyId": "cp_vendor456",
    "paymentReason": "PAYMENT_FOR_GOODS_AND_SERVICES",
    "confirm": true
  }'

rawValue is minor units (cents for USD). Destinations start IN_REVIEW and become payable only after screening — create the counterparty and external account first. Use a unique high-entropy Idempotency-Key on every write — see Idempotency. Request / accept — the agent collects. Create a transfer that returns depositInstructions, or share a standing fixed route / balance-account deposit address. Funds land on the customer’s account; listen for transfer.* webhooks. The console can generate a hosted pay page for an account id or a transfer awaiting deposit. Screening runs when the deposit or transfer is processed. Console invoicing emits invoice.* webhooks.

Transfer

One instruction: amount, currency, source, destination. Routing selects ACH, Fedwire, RTP, SWIFT, stablecoin, or FX from those fields. That is the product marketing calls Transfer Routes — in the API it is transfers plus fixed routes.

Need	Endpoint
One-off payout or collection	`POST /v1/transfers`
Lock a rate first	`POST /v1/quotes` then attach `quoteId`
Firm FX	`POST /v1/fx/quotes` → `POST /v1/fx/trades`
Standing inbound mailbox	`POST /v1/fixed-routes/virtual-bank-accounts` or `/virtual-wallets`
Batch payouts	`POST /v1/global-payout-batches`

Customer must be ACTIVE. Set confirm: true to submit immediately, or create a DRAFT and POST /v1/transfers/{id}/submit.

Credit

The liquidity facility draws USDC into a Solana treasury (POST /v1/liquidity/draws), then you pay back a position. Check with your account team — the facility is capability-gated.

Connect

Platform on Infinite is three existing calls:

Onboard your customer — POST /v1/customers/businesses (or /individuals), then a hosted verification link via POST /v1/verification/initiate, or submit verification over the API
Issue accounts to that cus_ once they are ACTIVE
Move money on their behalf — every transfer takes onBehalfOf: "cus_…"

For payees who are not the customer, create a counterparty (cp_) and attach it on the transfer. Child organizations (POST /v1/organizations/{id}/children) are a separate, capability-gated tenancy feature — not required for third-party funds flow.

Bill

Take your cut in the settlement path with developerFeeFixed and developerFeePercent on transfers and fixed routes. That is the funds-flow billing mechanism that is live today. Provider-balance onramp sweep targets do not support developer fees.

Identity

Layer	Object	Endpoint
Business (KYB)	Customer `type: BUSINESS`	`POST /v1/customers/businesses` + verification submit
Person (KYC)	Customer `type: INDIVIDUAL` or associated entity	`POST /v1/customers/individuals` or `/associated_individuals`
Hosted onboarding	Verification session `vsess_`	`POST /v1/verification/initiate`
Payee	Counterparty `cp_`	`POST /v1/counterparties`
Agent (KYA)	Agent `agt_` on a verified customer	`POST /v1/agents` — the agent inherits the customer’s verification

Capabilities (GET /v1/customers/{id}/capabilities) tell you what that customer may hold or send.

Observability

Subscribe to the supported lifecycle events below. Not every internal state change emits a customer webhook (for example draft transfer creation), so treat GET /v1/transfers/{id} — and the matching resource GET for customers, accounts, and verification — as the source of truth, with webhooks as the push path.

Signal	Where
State changes	Webhooks — `transfer.`, `customer.`, `verification.`, `counterparty.`, `external_account.in_review`, `external_account.approved`, `external_account.rejected`
Single payment	`GET /v1/transfers/{id}`
Recent API traffic	MCP `get_my_api_logs` / `get_my_api_errors`, or Developer → Request logs in the console

External accounts start IN_REVIEW and become payable after screening. Listen for external_account.approved (and external_account.rejected) to know when a payee destination is usable — counterparty.* only covers counterparty create / update / delete. When a transfer is held in IN_REVIEW, it stays there until a terminal status: COMPLETED, REVERSED, FAILED, or CANCELLED.

Compliance

Infinite’s compliance program screens customers, counterparties, and transfers. You see explicit statuses and, when more information is needed, RFIs. Approve / reject decisions are made by a human on Infinite’s side.

Need	Endpoint
What this customer still owes	`GET /v1/customers/{id}/compliance`
Open requests for information	`GET /v1/rfis` or `GET /v1/customers/{id}/rfis`
Verification state	`GET /v1/verification/customers/{id}`

Some review paths place a hard hold and move the transfer to IN_REVIEW (emits transfer.updated) until a human allows or blocks it. Transaction and account monitoring can also open a review case without holding settlement — do not treat a monitoring alert alone as a guarantee that funds stopped.

Next steps

Agents API reference

Every endpoint and field

Customers

Create the business the agent belongs to

Accounts

Issue the funded account that caps spend

Transfers

Pay, collect, and watch status

Webhooks

Signed events for every transition

MCP

Connect an assistant to your account

Get started

Core Concepts

Guides

Lifecycle

Create an agent

Issue a key

Pay as the agent

Limits

Owner approval

Attribution

Webhooks

Building blocks

Setting one up

What an agent needs

Wallet account

Pay, request, and accept

Transfer

Credit

Connect

Bill

Identity

Observability

Compliance

Next steps

Agents API reference

Customers

Accounts

Transfers

Webhooks

MCP

​Lifecycle

​Create an agent

​Issue a key

​Pay as the agent

​Limits

​Owner approval

​Attribution

​Webhooks

​Building blocks

​Setting one up

​What an agent needs

​Wallet account

​Pay, request, and accept

​Transfer

​Credit

​Connect

​Bill

​Identity

​Observability

​Compliance

​Next steps

Agents API reference

Customers

Accounts

Transfers

Webhooks

MCP

Lifecycle

Create an agent

Issue a key

Pay as the agent

Limits

Owner approval

Attribution

Webhooks

Building blocks

Setting one up

What an agent needs

Wallet account

Pay, request, and accept

Transfer

Credit

Connect

Bill

Identity

Observability

Compliance

Next steps