AOMI REST APIs
Add swaps, yield, transfers, and settlement to an existing product with one JSON API. Aomi plans, fork-simulates, and policy-checks every transaction; the customer's wallet signs. No custody, no new signing stack.
REST + JSON · OAuth 2.1 or guest · EVM + Solana · keys stay with your signer
TWO PORTS, ONE KERNEL
Both APIs end at the same execution boundary. The difference is whether Aomi resolves a customer's intent or the platform submits the exact action its own systems selected.
01 · AOMI RESOLVES THE INTENT
Send a user's intent and wallet capabilities. Receive messages, activity, and a durable action that can be approved by the signer already inside your product.
IN PRODUCTIONSommelier's liquidity assistant runs on this path.
02 · YOUR SYSTEM SELECTS THE ACTION
Select a catalog action or assemble a batch directly. Receive a Plan containing the simulation verdict, typed guard checks, and unsigned signable—with no Aomi inference or chat session.
IN PRODUCTIONWorld Markets' Telegram trading agent keeps its own strategy and submits through this path.
THE SHARED CONTRACT
Agent chat and pipeline builds resolve into the same durable, sealed approval object. One confirmation UI, one wallet binding, both APIs—move between them without rebuilding either.
POST /v1/agent/chatAuthorization: Bearer $AOMI_TOKENIdempotency-Key: 7c1e… { "message": "Swap 0.5 ETH to USDC on Base", "app": "aomi", "wallets": { "evm": { "address": "0xAb5…", "chainId": 8453 } } }interface ActionSummary { title: string steps: Step[] // what happens, in order cost: Cost // gas payer, fees, all-in warnings: Warning[] // empty = clean expiresAt: string | null} interface Step { label: string detail?: string asset?: { // present when value moves direction: 'out' | 'in' amount: string // human units, always symbol: string usd?: string }}filled by this exampletitlestepscostwarningsexpiresAt
event.action.summary// from a chat turn
rendered entirely from the type · the renderer maps over steps
A single swap, an ordered batch, a transfer waiting on a Safe quorum: the renderer never branches. Ship one confirm sheet and it covers everything either API will ever produce.
TWO APIS · ONE TRANSACTION PIPELINE
The Agent API accepts customer intent and lets Aomi plan. The Pipeline API accepts the exact action or batch your own agent, strategy, or product selected. Both resolve to the same Action contract and cross the same simulation, policy, signer, and verification boundary.
Aomi runs the agent loop, selects tools, and turns the conversation into a durable Action.
message + wallet capabilitiesKeep your own model, strategy, and routing logic. Submit one catalog action or an ordered batch directly.
ActionSpec | ActionSpec[]Resolve the customer's intent or accept the exact action and batch the integrator selected.
Run the complete batch against a fork before anything reaches a signer.
Enforce chain, signer, ordering, slippage, and application policy.
Return a sealed Action to the wallet adapter the product already trusts.
Observe the transaction and check it against the sealed Action before resuming.
Idempotent results and ordered state transitions make retries safe without duplicate execution or double-resuming a thread.
INSIDE THE HARNESS
Fundamentally, every harness that takes actions is mutating the state of the world its agent lives in — whether that world is a codebase, a file system, or a financial ledger. Aomi exposes that loop as an API: a typed action over a mutable world, judged by the world's end-state. Onchain, the world diverges at five points — a typed, gated action space, simulation as the only rehearsal, no unilateral write authority, irreversibility, and a shared, adversarial world.
INTEGRATION CHECKLIST
Answers from the v1 reference, in the order an integration review reaches them.
BUILD ON THE KERNEL
Integrating into an existing product? Start here. Want Aomi to host the agent and the customer-facing surface too? See the Human Interface and Plugin SDK—same Action, same signer, no rebuild when you move between them.