- Your backend asks the API for the payload to sign. The request carries the complete policy.
- The owner’s wallet signs
intent.payloadexactly as returned. - Your backend submits the signature and waits until the agent is
ACTIVE.
Prerequisites
- The setup and key check from the introduction, including
agent-api.ts. OWNER_ACCOUNT_IDandOWNER_PUBLIC_KEYin.env: a NEAR account and the public key of one of its full-access keys.
1
Find your tokens
GET /v1/tokens lists every token an agent can hold and trade. It’s public, so it needs no key. Note the asset_id of each token you want. You use these IDs in the policy and in every action.Amounts in the API are always whole numbers in the token’s smallest unit, as strings. With
decimals: 6, 1 USDC is "1000000". price is the USD price, or null when there’s no recent one. Treat null as unknown, not zero.2
Describe the owner
The owner is the wallet that controls the agent. Only public data goes here, never a private key.See Owner Accounts for the exact format rules. Read
supported_owner_types from GET /v1/network before you create an agent for another owner type. EVM owners aren’t enabled by default, and agent_create with one returns owner_type_unsupported. The rest of this quickstart uses the NEAR owner.3
Write the policy
The policy says what every grant on the account may do. You always send it complete, and the owner signs all of it at once. This one lets the agent:
- spend only USDC on Base and USDT on NEAR, at most 25 of each per transaction
- swap, transfer and withdraw, but only to the owner’s own account
- spend at most 50 USD a day across all assets
- run actions immediately, with no delay, schedule or approval vote
policy.ts.4
Generate the agent_create intent
Send the name, owner and policy. Add an
Idempotency-Key: if the request fails and you retry with the same key, you get the same result instead of a second agent. external_user_id is optional. Set it to your own user ID to find the agent later with GET /v1/agents?external_user_id=.Response fields
Response fields
5
Have the owner sign
Send Your frontend sends the result,
intent and preview to your frontend. Show the owner the preview, then have their wallet sign intent.payload exactly as you received it. Don’t change, rebuild or hash it. Pick the wallet method from intent.standard:Frontend
signed_data, back to your backend. See Owner Signing for each wallet in detail and Signing Standards for the formats.6
Submit the signature
Submit the object Sending the same signature twice is safe. The API pays the gas and installs the policy.
signWithWallet returned, unchanged. For cURL, set CORRELATION_ID to the correlation_id from the generate step and SIGNED_DATA to that object as JSON.7
Wait for the agent to go live
Check the status until it’s final.
When the status is
wait_ms=30000 makes each call wait up to 30 seconds for a change. If the status isn’t final yet, call again with the same correlation_id.Example status
Example status
SUCCESS, the agent is ACTIVE. agent.wallet.near_account_id is the agent’s NEAR Intents account, where funds arrive. Save agent.id as AGENT_ID in .env.8
Check the policy is in force
A signed policy only counts once it’s applied. Until then, actions fail with The response also carries
policy_not_ready.policy, the complete object you edit to change the rules, and usage, with each USD budget cap’s current period and the number of timelocked executions.You now have an
ACTIVE agent whose policy is in force. Save its ID in .env as AGENT_ID. That was owner signature 1 of 2.Next: Issue a Grant
Let your backend act for the agent.