Quickstart

Register an address you control, read its balances and receive a signed webhook. Use Try it on each linked API operation to send requests; its schema and generated examples describe the request format.

Before starting, choose an EVM address you control and prepare a publicly reachable HTTPS receiver. It must accept POST requests, verify webhook signatures using the raw request body and return 2xx after safely recording a delivery. See signature verification.

Sign up in the dashboard, create a workspace and a project, then issue a project API key. Grant api:blockchain:read, api:address:write, api:balance:read, api:activity:read, api:channel:write and api:subscription:write for this walkthrough.

Save the full key in a secrets manager: later reads expose only a preview and metadata. Enter it as X-Api-Key in the reference's authorization control. Keep it separate from the credentials used by your receiver. See Authentication.

Before each mutation, persist a distinct Idempotency-Key with the exact request body and the operation it represents. If the response is lost, retry that intent with the same key and body. Do not create a fresh key for an unknown outcome. See Idempotency for replay windows and recovery.

Open List blockchains and send the request with Try it. A successful response confirms that the key can read the network catalog. Save the CAIP-2 identifier of a supported EVM network for the address you chose, such as eip155:1 for Ethereum. Follow pagination when reading the catalog.

Open Create external address. Select the from_address example, set input.value to your own EVM address, keep input.chain_family as evm and choose a label you can recognize. Supply the saved idempotency key and send the request.

Keep the returned canonical address value and label for subsequent requests and reconciliation. Registration applies to its chain family; it does not transfer funds or grant Vilna signing authority. Other families have different support: solana registration and token resolution do not include balances or transaction monitoring. See Core concepts.

Use Summarize balances with family=evm for project holdings, or Search balances with the returned address in addresses to inspect this address. Optionally restrict the search to the selected network with chain_gids. Both results are paginated and scoped to one family; request other supported families separately.

Use List activity to read balance changes. An unused address can have no balance entries or activity. Use integer strings in base for arithmetic and formatted for display; see Amounts.

1. Open Create channel. Give it a recognizable name, select webhook configuration, set your receiver's HTTPS URL and choose payload_version: v2. Send it with its own persisted idempotency key. Save the returned channel id, name and webhook_secret immediately. Secret-bearing creation responses have a limited replay window; see Idempotency.
2. Open Test channel, supply the saved channel ID and choose family=evm. Use a separate persisted idempotency key. A 202 response means the test was accepted, not delivered. Check your receiver for the signed test delivery and its 2xx response. This test checks delivery without waiting for blockchain activity and does not create a subscription.
3. Open Create subscription. Give it a name, use the saved channel_id, set family=evm and select a block trigger with after_blocks: 0. To restrict it to the chosen network, set filters.chain_gids to that network ID. Set is_noise_filtered: true. Persist this intent and body before sending. Keep the returned subscription ID and name. A new configuration returns 201; an exact configuration match can return 200.
4. Wait for a matching new transaction involving a monitored address. A subscription does not create blockchain activity. Confirm that your receiver verifies and records a real event, distinguished from the channel test by is_test: false.

The after_blocks: 0 notification is an early inclusion signal, not finality. Apply your confirmation policy and reconcile transaction state before crediting funds. See Events and monitoring and the reconciliation workflow.

Keep the event ID for duplicate handling and the channel and subscription IDs for later management. Use Integration patterns to extend this setup for deposits, treasury views or invoices.