Platform API supports 5 mainnets and 4 testnets. 7 networks support full monitoring; Solana Mainnet and Testnet support addresses and the token catalog only. See the networks table for CAIP-2 IDs and product support; GET /blockchains returns the live set.
Platform API monitors and reconciles public chain activity; it does not sign or broadcast transactions. VKS coordinates account setup, signer approvals and signing; a complete signed transaction can optionally be sent to a node through VKS. Node acceptance is not blockchain confirmation.
For API calls, use a service-specific credential:
- Platform API - blockchain monitoring: addresses, balances, transactions, invoices, notifications.
- Management API - administration: workspaces, projects, members, and API-key lifecycle.
- VKS - signers, vaults, accounts and transaction signing.
- Blockchain RPC - direct node access over JSON-RPC and gRPC, one key for every chain.
Sign up at app.vilna.io, create a workspace and a project, then generate an API key with the permissions you need. The platform is free during the early access period; see the Quickstart. For help, email support@vilna.io.
Send an API key in the X-Api-Key header on every authenticated API request - no OAuth flow, no token to refresh. Key types and scopes are covered in Authentication.
Limits depend on the API and operation. A temporal limit returns 429; follow the operation's retry rules and any Retry-After header. RPC has its own error formats and does not return X-RateLimit-* headers. See Errors.
External addresses are imported directly: you provide the full address string. HD addresses are derived from an extended public key (xPub) using BIP-32/44, so you can generate new addresses programmatically without exposing private keys. See Blockchain basics.
Yes. For EVM-compatible chains, setting input.chain_family to evm when you create the address monitors it on all active EVM networks at once.
Many transaction and balance amounts have base for exact calculations and formatted for display. Invoice fields differ between authenticated and public responses; see amount formats.
Balances cover native coins and tokens that are is_verified (the shared list) or is_trusted (your project's selection). The default incoming-transfer notification filter uses these marks, but a selected address's own action can also qualify; turning the filter off admits unfamiliar tokens without starting balances. Resolve the contract with POST /tokens/{chain_gid}/{asset_path}, then POST …/actions/trust; past transactions stay silent. See Tokens and balances.
A subscription chooses one trigger: block waits a fixed number of blocks after inclusion, network waits for the chain's own confirmation policy, mempool (Bitcoin only) fires before inclusion. For an early signal and a later confirmation signal, create two subscriptions with different triggers. Meeting the confirmation policy does not guarantee irreversibility. See Events & monitoring.
Two: webhooks (a signed HTTP POST to your endpoint) and Telegram (bot messages to a chat). See Notification channels for setup.
Check the X-Webhook-Signature header: it carries t=<unix>,v1=<hex>, an HMAC-SHA256 of the t value, a literal dot and the raw request-body bytes, keyed with webhook_secret. Reject deliveries whose timestamp is stale (replay protection) and deduplicate by X-Webhook-Event-Id. The Webhooks page has the step-by-step algorithm.
Yes. A channel test sends a signed sample marked is_test: true, without a real transaction. The request returns 202 with a notification_id; inspect the notification to confirm delivery. See Testing a channel.
A delivery that doesn't return 2xx (or times out) is retried on a fixed schedule with a growing delay. Retries reuse the same event_id, so your deduplication keeps them safe, and every attempt is recorded in the notification history. max_attempts bounds those retries; once it is used up the channel disables itself - see the next two questions.
No. The knob is max_attempts, 1 to 10 per channel, raised with PATCH /channels/{channel_id}. Once a notification uses up the budget the channel is disabled and its waiting notifications are cancelled; re-enabling admits new transactions only. See when a channel switches itself off.
No. Transactions, activity and balances are recorded whether or not a notification went out; only the deliveries were cancelled. Poll GET /channels for is_enabled: false. After re-enabling, list the cancelled notifications and the activity for that window, and resend the ones that still have a payload. The payment flow recipe walks through it.
No. Vilna is a standard REST API; call it directly from any language over HTTP. If you want typed client code, generate it from the OpenAPI specification using a tool like openapi-generator.
Yes. The Vilna docs MCP server lets Claude and other MCP clients read the full API reference in context and scaffold correct calls. See AI integration.
Chain Agnostic Improvement Proposals give every chain, account and asset one identifier shape: CAIP-2 for chains, CAIP-10 for accounts, CAIP-19 for assets. Vilna uses them as ids throughout the API. See Standards for how each one is built.
The Platform, Management and VKS HTTP APIs use RFC 7807 Problem Details (application/problem+json). Branch on the machine-readable code; Blockchain RPC uses protocol errors. See Errors.