Platform API поддерживает 5 основных и 4 тестовые сети. В 7 сетях доступен полный мониторинг; Solana Mainnet и Testnet поддерживают только адреса и каталог токенов. Идентификаторы CAIP-2 и возможности продуктов указаны в таблице сетей; GET /blockchains возвращает актуальный набор.
Platform API наблюдает за публичной активностью и сверяет её; он не подписывает и не отправляет транзакции. VKS отдельно координирует создание блокчейн-аккаунтов, согласование и подпись с участием узлов подписи (signer); готовую транзакцию можно отправить узлу. Принятие узлом не означает подтверждения в блокчейне.
Для вызовов API используйте ключ соответствующего сервиса:
- Platform API - мониторинг блокчейна: адреса, балансы, транзакции, счета, уведомления.
- Management API - администрирование: пространства, проекты, участники и жизненный цикл API-ключей.
- VKS - настройка блокчейн-аккаунтов, согласование и совместная подпись транзакций.
- Blockchain RPC - прямой доступ к узлам по JSON-RPC и gRPC, один ключ для каждой сети.
Зарегистрируйтесь на app.vilna.io, создайте рабочее пространство и проект, затем сгенерируйте API-ключ с нужными правами. Платформа бесплатна на этапе раннего доступа; см. Быстрый старт. Если нужна помощь, пишите на support@vilna.io.
Передавайте API-ключ в заголовке X-Api-Key в каждом аутентифицированном API-запросе. Без потока OAuth и без токена, который нужно обновлять. Типы ключей и права рассмотрены в разделе Аутентификация.
Лимиты зависят от API и операции. Временное ограничение возвращает 429; соблюдайте правила повторов операции и Retry-After, если он есть. У RPC свои форматы ошибок, заголовков X-RateLimit-* нет. См. Ошибки.
Внешние адреса импортируются напрямую: вы указываете полную строку адреса. HD-адреса деривируются из расширенного публичного ключа (xPub) по стандартам BIP-32/44, что позволяет программно генерировать новые адреса без раскрытия приватных ключей. См. Основы блокчейна.
Да. Для EVM-совместимых сетей достаточно указать input.chain_family со значением evm при создании адреса, и он будет отслеживаться во всех активных EVM-сетях сразу.
Многие суммы транзакций и балансов содержат base для точных вычислений и formatted для отображения. Поля счетов отличаются в аутентифицированных и публичных ответах; см. форматы сумм.
Балансы охватывают нативные монеты и токены с is_verified (общий список) или is_trusted (выбор проекта). Фильтр уведомлений о входящих переводах по умолчанию использует эти метки, но действие самого выбранного адреса тоже может дать основание; отключение фильтра допускает незнакомые токены без включения балансов. Разрешите контракт через POST /tokens/{chain_gid}/{asset_path}, затем POST …/actions/trust; прошлые транзакции остаются без уведомлений. См. Токены и балансы.
Подписка использует одно условие отправки уведомления (trigger): block ждёт фиксированное число блоков после включения, network ждёт собственной политики подтверждений сети, mempool (только Bitcoin) срабатывает до включения в блок. Для раннего сигнала и более позднего сигнала подтверждения создайте две подписки с разными условиями. Выполнение политики подтверждений не гарантирует необратимости. См. События и мониторинг.
Два: вебхуки (подписанный HTTP POST на ваш эндпоинт) и Telegram (сообщения бота в чат). Настройка описана в разделе Каналы уведомлений.
Проверьте заголовок X-Webhook-Signature: он содержит t=<unix>,v1=<hex>, HMAC-SHA256 от значения t, точки и сырых байтов тела запроса с ключом webhook_secret. Отбрасывайте доставки с устаревшей временной меткой (защита от повторов) и исключайте повторную обработку по X-Webhook-Event-Id. Пошаговый алгоритм есть на странице Webhooks.
Да. Тест канала отправляет подписанный пример с is_test: true без реальной транзакции. Запрос возвращает 202 и notification_id; проверьте уведомление, чтобы подтвердить доставку. См. Проверка канала.
Доставка, которая не вернула 2xx (или истекла по таймауту), повторяется по фиксированному расписанию с растущей задержкой. Повторы используют тот же event_id, поэтому обработчик может распознать повтор и не выполнять действие снова. Каждая попытка записывается в историю уведомлений. max_attempts ограничивает эти повторы; когда он исчерпан, канал отключается сам - см. два следующих вопроса.
Нет. Настройка - это max_attempts, от 1 до 10 на канал, повышается через PATCH /channels/{channel_id}. Когда уведомление исчерпало бюджет, канал отключается, а ожидающие уведомления отменяются; повторное включение принимает только новые транзакции. См. когда канал отключается сам.
Нет. Транзакции, активность и балансы записываются независимо от того, ушло ли уведомление; отменены только доставки. Опрашивайте GET /channels по is_enabled: false. После включения запросите отменённые уведомления и активность за это окно и отправьте заново те, у которых ещё сохранено тело уведомления. Пошагово это разобрано в рецепте для платёжного потока.
Нет. Vilna - это стандартный REST API, вызывайте его напрямую из любого языка через HTTP. Если нужен типизированный клиент, сгенерируйте его из OpenAPI-спецификации с помощью инструмента вроде openapi-generator.
Да. MCP-сервер документации Vilna позволяет Claude и другим MCP-клиентам читать полный справочник API в контексте и генерировать корректные вызовы. См. Интеграция с ИИ.
Chain Agnostic Improvement Proposals дают каждой сети, адресу в конкретной сети и активу единую форму идентификатора: CAIP-2 для сетей, CAIP-10 для адресов в конкретной сети, CAIP-19 для активов. Vilna использует их как идентификаторы по всему API. В разделе Стандарты показано, как устроен каждый из них.
Platform, Management и VKS HTTP API используют RFC 7807 Problem Details (application/problem+json). Проверяйте машинный code; для Blockchain RPC действует модель ошибок протокола. См. Ошибки.