Obsidian REST API vs Webhooks: что выбрать?

Два инструмента, одна цель: получить внешние данные в Obsidian. Но они работают совершенно противоположными способами. Один превращает Obsidian в сервер, у которого вы запрашиваете данные. Другой доставляет данные в Obsidian независимо от того, запущен он или нет.

Если вы автоматизируете Obsidian или подключаете его к внешним сервисам, вы наверняка сталкивались с обоими подходами. Это руководство объясняет, когда использовать REST API, когда webhooks, а когда оба вместе.

Краткое сравнение

Характеристика	Local REST API Plugin	Webhooks Server
Направление	Pull (вы запрашиваете данные)	Push (данные приходят автоматически)
Obsidian должен быть запущен?	Да, всегда	Нет (очередь при офлайне)
Обновления в реальном времени?	Только по запросу	SSE streaming
Self-hosted?	Только plugin	Полный server + plugin
Операции	Полный CRUD (create, read, update, delete, search)	Create/Append/Overwrite
Аутентификация	API key	Magic links + AES-256-GCM шифрование
Сеть	Локальная сеть	Интернет (self-hosted server)
Лучше всего для	Чтение заметок из приложений, полный контроль	Получение данных от внешних сервисов
Поддержка	Активный (2800+ stars)	Активный

Как работает Obsidian Local REST API

Local REST API plugin от coddingtonbear превращает десктопное приложение Obsidian в веб-сервер. Когда Obsidian запущен, он предоставляет HTTP endpoints, которые вы можете вызывать для:

• Create — создание новых заметок
• Read — чтение существующих заметок (получение контента, поиск)
• Update — обновление содержимого заметок
• Delete — удаление заметок
• Search — поиск по хранилищу

Это модель запрос-ответ. Ваше внешнее приложение (Python-скрипт, мобильное приложение, другой сервис) отправляет HTTP-запросы в Obsidian, и Obsidian отвечает данными или подтверждает действие.

Аутентификация использует API key, который вы настраиваете в параметрах плагина. Для безопасности плагин использует HTTPS с самоподписанными сертификатами.

Ключевое ограничение: Obsidian должен быть запущен на вашем компьютере. Если вы закрываете Obsidian, API становится недоступен, и внешние запросы не работают.

Пример использования: панель мониторинга читает Obsidian

Вы создаете веб-панель, которая отображает ваши ежедневные заметки, количество задач и недавние записи в журнале. Панель должна:

1. Читать текущую ежедневную заметку
2. Искать незавершенные задачи
3. Считать записи по тегам

С плагином Local REST API ваша панель отправляет GET-запросы в Obsidian всякий раз, когда ей нужны свежие данные. Obsidian отвечает содержимым заметки, результатами поиска или метаданными.

Это работает идеально, потому что:

• Вам нужно читать данные (сильная сторона REST API)
• Obsidian запущен, пока вы используете панель
• Вы контролируете, когда происходят запросы (по требованию)

Как работает Obsidian Webhooks Server

Obsidian Webhooks Server — это событийно-ориентированная архитектура. Внешние сервисы отправляют данные на ваш self-hosted сервер через webhook POST-запросы. Сервер:

1. Получает webhook-нагрузку от любого интернет-сервиса
2. Ставит в очередь в PostgreSQL (сохраняется, даже если Obsidian закрыт)
3. Доставляет через Server-Sent Events (SSE) в плагин Obsidian, когда он подключается
4. Подтверждает доставку с exactly-once семантикой (ACK-механизм)
5. Шифрует чувствительный контент с помощью AES-256-GCM

Это push-модель. Вы не запрашиваете данные; данные приходят и стоят в очереди, пока Obsidian не будет готов их получить. Подробнее об архитектуре — в руководстве Как работает Obsidian Webhooks.

Аутентификация использует magic links, генерируемые сервером. Никаких API keys в конфигах внешних сервисов. Webhook URL подписаны и зашифрованы.

Ключевое преимущество: Obsidian не обязан быть запущенным. Webhooks стоят в очереди на стороне сервера и доставляются автоматически, когда вы в следующий раз откроете Obsidian.

Пример использования: захват идей отовсюду

Вы используете несколько сервисов, которые должны создавать заметки в Obsidian:

1. Telegram bot — пересылка сообщений для сохранения идей
2. Zapier — сохранение помеченных писем в ежедневные заметки
3. n8n — сводки RSS-лент в inbox для чтения
4. GitHub Actions — результаты CI в виде заметок

С Webhooks Server:

• Каждый сервис отправляет POST-запрос на ваш webhook URL
• Сервер ставит все входящие данные в очередь
• Когда вы открываете Obsidian (даже через несколько часов), плагин подключается через SSE
• Все заметки из очереди доставляются и создаются автоматически
• Вы получаете подтверждения доставки для каждого webhook

Это работает, потому что:

• Внешние сервисы проталкивают данные по своему расписанию
• Нет зависимости от того, открыт ли Obsidian
• Доставка гарантирована даже после перезагрузок

Готовые конфигурации для Zapier, Make, n8n и IFTTT смотрите в 10 рецептах автоматизации.

Когда использовать Local REST API Plugin

Выбирайте подход REST API, когда:

Вам нужно читать заметки из внешних приложений

Если вашему внешнему приложению нужно получать данные из Obsidian, REST API — единственный вариант. Webhooks не могут отдавать содержимое заметок другим приложениям — они только доставляют входящие данные.

Сценарии:

• Мобильное приложение, отображающее ваши заметки
• Веб-панель, показывающая статистику хранилища
• Python-скрипт, анализирующий ваши записи в журнале
• Десктопное приложение, синхронизирующееся с контентом Obsidian

Вам нужны полные CRUD-операции

Если вам нужно обновлять существующие заметки, удалять заметки или искать по хранилищу программно, REST API предоставляет все эти операции. Webhooks Server фокусируется на создании/добавлении нового контента, а не на изменении существующих заметок.

Сценарии:

• Менеджер задач, синхронизирующий статус завершения
• Редактор заметок, изменяющий черновики
• Скрипт очистки, удаляющий старые ежедневные заметки
• Инструмент поиска, индексирующий контент хранилища

Obsidian всегда запущен

Если вы работаете за компьютером, где Obsidian остается открытым в рабочие часы, требование REST API о запущенном приложении не является ограничением.

Сценарии:

• Домашний офис с настольным компьютером, который всегда включен
• Настройка для одного пользователя с предсказуемым графиком
• Автоматизация локальной сети (без зависимости от интернета)

Вы хотите установку только с plugin

REST API требует только установки плагина Obsidian. Никаких внешних серверов, Docker, PostgreSQL. Если вы предпочитаете простоту и вам не нужна очередь в офлайне, это более легкая инфраструктура.

Когда использовать Obsidian Webhooks Server

Выбирайте подход webhooks, когда:

Внешние сервисы должны проталкивать данные

Если платформы автоматизации, API или сервисы генерируют данные, которые должны попасть в Obsidian, webhooks устраняют необходимость в polling и обеспечивают немедленную доставку.

Сценарии:

• Zapier — сохранение меток Gmail, закладок Slack, лайков Twitter
• Make (Integromat) — RSS-ленты, события календаря, формы
• n8n — кастомные workflow, мониторинг API, запланированные отчеты
• IFTTT — IoT-триггеры, заметки на основе местоположения, архивы соцсетей

Вы не всегда за компьютером

Если вы путешествуете, работаете из нескольких мест или не держите Obsidian запущенным 24/7, webhooks ставят данные в очередь, пока вы не вернетесь.

Сценарии:

• Workflow с приоритетом на мобильных устройствах
• Использование нескольких устройств (ноутбук + настольный ПК)
• Идеи, захваченные на ходу (Telegram, голосовые заметки)
• Запланированные задания, выполняющиеся, пока вы спите

Вам нужны гарантии доставки

Webhooks Server обеспечивает exactly-once доставку с подтверждением. Если Obsidian падает во время доставки, заметка возвращается в очередь и повторяется. REST API требует, чтобы ваше внешнее приложение обрабатывало повторы.

Сценарии:

• Финансовые данные (нельзя потерять транзакции)
• Отзывы клиентов (критичные бизнес-данные)
• Исследовательские цитаты (нельзя потерять источники)
• Логирование для соответствия требованиям (аудит)

Вам нужно зашифрованное хранение

Если webhook-нагрузка содержит чувствительные данные (API keys, персональная информация, учетные данные), Webhooks Server шифрует их в состоянии покоя с помощью AES-256-GCM. REST API обрабатывает запросы немедленно, но не обеспечивает зашифрованную постановку в очередь.

Сценарии:

• Webhooks с данными о здоровье
• Интеграции с финансовыми API
• Токены аутентификации в заметках
• Личные записи в журнале из внешних приложений

Вы используете несколько хранилищ или устройств

Webhooks Server может направлять данные в разные хранилища на разных устройствах, используя magic links. REST API обслуживает одно хранилище на экземпляр Obsidian.

Сценарии:

• Рабочее хранилище + личное хранилище
• Настольный ПК + ноутбук + планшет
• Командная совместная работа (отдельные хранилища для каждого пользователя)

Можно ли использовать оба вместе?

Абсолютно. REST API и Webhooks Server решают разные проблемы и идеально дополняют друг друга.

Пример гибридной архитектуры

Ваша настройка:

• Webhooks Server получает входящие данные от Zapier, GitHub, Telegram
• REST API plugin отдает содержимое заметок вашей кастомной панели
• Obsidian действует и как потребитель webhook, и как сервер REST API

Потоки данных:

1. Входящие (Push)

Zapier отправляет помеченные письма → Webhooks Server → В очереди → Доставлено в Obsidian → Новые заметки в папке ежедневных

2. Исходящие (Pull)

• Ваша панель отправляет GET-запрос → REST API plugin → Возвращает содержимое ежедневной заметки
• Python-скрипт ищет #task → REST API plugin → Возвращает список задач

Почему это работает:

• Webhooks обрабатывают "данные, приходящие извне"
• REST API обрабатывает "внешние приложения, читающие Obsidian"
• Нет конфликта; они работают в разных направлениях

Реальный пример гибридного использования

Утренний workflow:

1. Ночью GitHub Actions завершает CI-прогоны → Отправляет результаты через webhook → В очереди
2. Twitter-бот архивирует ваши сохраненные треды → Webhook → В очереди
3. Агрегатор RSS отправляет сводки статей → Webhook → В очереди

Вы открываете Obsidian в 9 утра:

• Все webhooks из очереди доставляются мгновенно через SSE
• Заметки появляются в целевых папках

В 10 утра вы открываете свою кастомную панель:

• Панель вызывает REST API: GET /vault/Daily/2026-02-26.md
• REST API возвращает сегодняшнюю заметку (включая контент, созданный webhook)
• Панель отображает задачи, ссылки, сводки

Обе системы работают вместе: webhooks доставили контент, REST API отдал его обратно другому приложению.

Дерево решений: что использовать?

Пройдите через это дерево решений, чтобы найти ответ:

Вопрос 1: Нужно ли вам ЧИТАТЬ заметки из внешнего приложения?

• Да → Вам нужен REST API (webhooks не могут отдавать контент)
• Нет → Переходите к Вопросу 2

Вопрос 2: Должны ли внешние сервисы ПРОТАЛКИВАТЬ данные в Obsidian?

• Да → Переходите к Вопросу 3
• Нет → Используйте REST API для полного контроля

Вопрос 3: Всегда ли запущен Obsidian, когда приходят данные?

• Да → REST API может работать; подумайте о простоте настройки (только plugin vs сервер)
• Нет → Используйте Webhooks Server (очередь при офлайне)

Вопрос 4: Нужны ли вам полные CRUD-операции (update, delete, search)?

• Да → Используйте REST API (webhooks только create/append)
• Нет → Подходит любой вариант; учитывайте требования к офлайну

Вопрос 5: Нужны ли вам потоки данных в обоих направлениях?

• Да → Используйте REST API + Webhooks Server
• Нет → Выбирайте на основе направления (входящие = webhooks, исходящие = REST API)

Быстрые сценарии

Сценарий	Решение
Панель, читающая заметки	Только REST API
Telegram-бот, сохраняющий идеи	Только Webhooks
Zapier + панель вместе	REST API + Webhooks
Обновление заметок из приложения	Только REST API
Получение писем как заметок	Только Webhooks
Мобильное приложение для черновиков	Только REST API
RSS-ленты в заметки	Только Webhooks
Синхронизация задач с менеджером	Только REST API
Захват идей с нескольких устройств	Только Webhooks

Вопросы реализации

Для REST API

Сложность настройки: Низкая (только установка plugin)

Сетевые требования: Доступ к локальной сети до машины с Obsidian; перенаправление портов для удаленного доступа

Безопасность: Аутентификация по API key, HTTPS с самоподписанными сертификатами

Надежность: Зависит от uptime Obsidian; внешнее приложение должно обрабатывать отказы

Лучшие практики:

• Используйте ротацию API key
• Ограничивайте сетевой доступ (правила firewall)
• Реализуйте логику повторов во внешних приложениях
• Мониторьте доступность Obsidian

Для Webhooks Server

Сложность настройки: Средняя (Docker Compose, PostgreSQL, установка plugin). Пошаговая инструкция — в руководстве по установке.

Сетевые требования: Сервер с доступом из интернета (VPS, домашний сервер с доменом)

Безопасность: Magic links, AES-256-GCM шифрование, проверка подписи webhook

Надежность: Очередь обеспечивает доставку; переживает перезапуски Obsidian

Лучшие практики:

• Запускайте на надежном сервере (не ноутбук)
• Настройте мониторинг (алерты о глубине очереди)
• Делайте бэкап базы данных PostgreSQL
• Используйте секреты окружения для ключей шифрования

Начало работы

Попробуйте Local REST API Plugin

1. Установите из Obsidian Community Plugins: "Local REST API"
2. Включите plugin, установите API key в настройках
3. Протестируйте с помощью curl:

curl -H "Authorization: Bearer YOUR_API_KEY" \
     https://127.0.0.1:27124/vault/

4. Постройте интеграцию, используя документацию API

Лучший первый проект: Python-скрипт, который ищет незавершенные задачи и выводит их в терминал.

Попробуйте Obsidian Webhooks Server

1. Разверните сервер: руководство по развертыванию на GitHub
2. Установите плагин Obsidian (companion repo)
3. Сгенерируйте magic link в админ-панели сервера
4. Протестируйте с помощью webhook:

curl -X POST https://your-server.com/w/YOUR_WEBHOOK_ID \
     -H "Content-Type: application/json" \
     -d '{"vault":"Default","path":"Test.md","content":"Hello"}'

5. Откройте Obsidian, увидите, как появляется заметка

Лучший первый проект: Telegram-бот, который пересылает сообщения в Obsidian через webhook.

Заключение

Obsidian Local REST API и Webhooks Server — это не конкурирующие решения, а инструменты для разных задач.

Выбирайте REST API, когда вам нужно вытягивать данные из Obsidian или изменять заметки из внешних приложений. Это правильный выбор для панелей, мобильных приложений и двунаправленной синхронизации.

Выбирайте Webhooks, когда внешние сервисы должны надежно проталкивать данные в Obsidian, особенно когда Obsidian не всегда запущен. Идеально для платформ автоматизации, запланированных заданий и multi-device workflow.

Используйте оба, когда у вас сложные интеграции с данными, текущими в обоих направлениях.

Хорошая новость? Вам не обязательно выбирать только один. Установите оба и постройте именно ту архитектуру автоматизации, которая нужна вашему workflow.

---

Ресурсы

• Local REST API Plugin — репозиторий на GitHub
• Obsidian Webhooks Server — репозиторий на GitHub
• Webhooks Server Landing Page — документация и примеры

Связанное чтение:

• Как работает Obsidian Webhooks — архитектура и настройка
• Как получать данные в Obsidian — полное руководство по входящим данным
• Self-Hosted: руководство по установке — Docker, PostgreSQL, Nginx
• 10 рецептов автоматизации — готовые конфигурации
• AI-агенты и Obsidian — интеграция Claude, GPT и кастомных агентов