Obsidian REST API vs Webhooks

Two tools, one goal: get external data into Obsidian. But they work in completely opposite ways. One turns Obsidian into a server you request data from. The other delivers data to Obsidian whether it's running or not.

If you're automating Obsidian or connecting it to external services, you've probably encountered both approaches. This guide breaks down when to use REST API, when to use webhooks, and when to use both together.

Quick Comparison

Feature	Local REST API Plugin	Webhooks Server
Direction	Pull (you request data)	Push (data arrives automatically)
Obsidian must be running?	Yes, always	No (queues when offline)
Real-time updates?	On-demand only	SSE streaming
Self-hosted?	Plugin only	Full server + plugin
Operations	Full CRUD (create, read, update, delete, search)	Create/Append/Overwrite
Authentication	API key	Magic links + AES-256-GCM encryption
Network	Local network	Internet (self-hosted server)
Best for	Reading notes from apps, full note control	Receiving data from external services
Maintenance	Active (2800+ stars)	Active

How Obsidian Local REST API Works

The Local REST API plugin by coddingtonbear turns your Obsidian desktop app into a web server. When Obsidian is running, it exposes HTTP endpoints you can call to:

• Create new notes
• Read existing notes (get content, search)
• Update note content
• Delete notes
• Search across your vault

This is a request-response model. Your external application (a Python script, a mobile app, another service) makes HTTP requests to Obsidian, and Obsidian responds with data or confirms the action.

Authentication uses an API key you configure in the plugin settings. For security, the plugin uses HTTPS with self-signed certificates.

The key constraint: Obsidian must be running on your computer. If you close Obsidian, the API is unavailable, and external requests fail.

Example Use Case: Dashboard Reading Obsidian

You're building a web dashboard that displays your daily notes, task counts, and recent journal entries. The dashboard needs to:

1. Read the current daily note
2. Search for incomplete tasks
3. Count entries by tag

With the Local REST API plugin, your dashboard sends GET requests to Obsidian whenever it needs fresh data. Obsidian responds with note content, search results, or metadata.

This works perfectly because:

• You need to read data (REST API's strength)
• Obsidian is running while you're using the dashboard
• You control when requests happen (on-demand)

How Obsidian Webhooks Server Works

Obsidian Webhooks Server is an event-driven architecture. External services send data to your self-hosted server via webhook POST requests. The server:

1. Receives webhook payloads from any internet service
2. Queues them in PostgreSQL (persists even if Obsidian is closed)
3. Delivers via Server-Sent Events (SSE) to the Obsidian plugin when it connects
4. Confirms delivery with exactly-once semantics (ACK mechanism)
5. Encrypts sensitive content with AES-256-GCM

This is a push model. You don't request data; data arrives and queues until Obsidian is ready to receive it.

Authentication uses magic links generated by the server. No API keys in external service configs. Webhook URLs are signed and encrypted.

The key advantage: Obsidian doesn't need to be running. Webhooks queue server-side and deliver automatically when you next open Obsidian. For a deeper look at the architecture, see How It Works.

Example Use Case: Capturing Ideas from Anywhere

You use multiple services that should create notes in Obsidian:

1. Telegram bot — Forward messages to save ideas
2. Zapier — Save starred emails to daily notes
3. n8n — RSS feed summaries to reading inbox
4. GitHub Actions — CI results as notes

With Webhooks Server:

• Each service sends a POST request to your webhook URL
• The server queues all incoming data
• When you open Obsidian (even hours later), the plugin connects via SSE
• All queued notes are delivered and created automatically
• You get delivery confirmations for each webhook

This works because:

• External services push data on their schedule
• No dependency on Obsidian being open
• Delivery is guaranteed even across restarts

For step-by-step integration examples with Zapier, Make, n8n, and more, see 10 Automation Recipes.

When to Use Local REST API Plugin

Choose the REST API approach when:

You Need to Read Notes from External Apps

If your external application needs to fetch data from Obsidian, REST API is the only option. Webhooks can't serve note content to other applications — they only deliver inbound data.

Scenarios:

• Mobile app displaying your notes
• Web dashboard showing vault statistics
• Python script analyzing your journal entries
• Desktop app syncing with Obsidian content

You Need Full CRUD Operations

If you need to update existing notes, delete notes, or search the vault programmatically, REST API provides all these operations. Webhooks Server focuses on creating/appending new content, not modifying existing notes.

Scenarios:

• Task manager syncing completion status
• Note editor app modifying drafts
• Cleanup script deleting old daily notes
• Search tool indexing vault content

Obsidian Is Always Running

If you work at a desktop where Obsidian stays open during work hours, REST API's requirement of a running app isn't a limitation.

Scenarios:

• Home office with always-on desktop
• Single-user setup with predictable hours
• Local network automation (no internet dependency)

You Want Plugin-Only Setup

REST API requires only installing an Obsidian plugin. No external servers, no Docker, no PostgreSQL. If you prefer simplicity and don't need offline queuing, this is lighter infrastructure.

When to Use Obsidian Webhooks Server

Choose the webhooks approach when:

External Services Need to Push Data

If automation platforms, APIs, or services generate data that should land in Obsidian, webhooks eliminate polling and provide immediate delivery.

Scenarios:

• Zapier — Save Gmail labels, Slack bookmarks, Twitter likes
• Make (Integromat) — RSS feeds, calendar events, form submissions
• n8n — Custom workflows, API monitoring, scheduled reports
• IFTTT — IoT triggers, location-based notes, social media archives

You're Not Always at Your Computer

If you travel, work from multiple locations, or don't keep Obsidian running 24/7, webhooks queue data until you're back.

Scenarios:

• Mobile-first workflows
• Multi-device usage (laptop + desktop)
• Ideas captured on-the-go (Telegram, voice notes)
• Scheduled jobs running while you sleep

You Need Delivery Guarantees

Webhooks Server provides exactly-once delivery with acknowledgment. If Obsidian crashes mid-delivery, the note is re-queued and retried. REST API requires your external app to handle retries.

Scenarios:

• Financial data (can't lose transactions)
• Customer feedback (critical business data)
• Research citations (must not drop sources)
• Compliance logging (audit requirements)

You Want Encrypted Storage

If webhook payloads contain sensitive data (API keys, personal info, credentials), Webhooks Server encrypts them at rest with AES-256-GCM. REST API processes requests immediately but doesn't provide encrypted queueing.

Scenarios:

• Health data webhooks
• Financial API integrations
• Authentication tokens in notes
• Private journal entries from external apps

You Run Multiple Vaults or Devices

Webhooks Server can route to different vaults on different devices using magic links. REST API serves one vault per Obsidian instance.

Scenarios:

• Work vault + personal vault
• Desktop + laptop + tablet setups
• Team collaboration (separate vaults per user)

Can You Use Both Together?

Absolutely. REST API and Webhooks Server solve different problems and complement each other perfectly.

Hybrid Architecture Example

Your setup:

• Webhooks Server receives inbound data from Zapier, GitHub, Telegram
• REST API plugin serves note content to your custom dashboard
• Obsidian acts as both webhook consumer and REST API server

Data flows:

1. Inbound (Push)

Zapier sends starred emails → Webhooks Server → Queued → Delivered to Obsidian → New notes in daily folder

2. Outbound (Pull)

• Your dashboard sends GET request → REST API plugin → Returns daily note content
• Python script searches for #task → REST API plugin → Returns task list

Why this works:

• Webhooks handle "data arriving from outside"
• REST API handles "external apps reading Obsidian"
• No conflict; they operate on different directions

Real-World Hybrid Use Case

Morning workflow:

1. Overnight, GitHub Actions finish CI runs → Send results via webhook → Queued
2. Twitter bot archives your bookmarked threads → Webhook → Queued
3. RSS aggregator sends article summaries → Webhook → Queued

You open Obsidian at 9 AM:

• All queued webhooks deliver instantly via SSE
• Notes appear in their target folders

At 10 AM, you open your custom dashboard:

• Dashboard calls REST API: GET /vault/Daily/2026-02-26.md
• REST API returns today's note (including webhook-created content)
• Dashboard displays tasks, links, summaries

Both systems working together: webhooks delivered the content, REST API served it back to another app.

Decision Tree: Which Should You Use?

Work through this decision tree to find your answer:

Question 1: Do you need to READ notes from an external app?

• Yes → You need REST API (webhooks can't serve content)
• No → Continue to Question 2

Question 2: Do external services need to PUSH data to Obsidian?

• Yes → Continue to Question 3
• No → Use REST API for full control

Question 3: Is Obsidian always running when data arrives?

• Yes → REST API can work; consider setup simplicity (plugin-only vs server)
• No → Use Webhooks Server (queues when offline)

Question 4: Do you need full CRUD operations (update, delete, search)?

• Yes → Use REST API (webhooks are create/append only)
• No → Either works; consider offline requirements

Question 5: Do you need both inbound and outbound data flows?

• Yes → Use both REST API + Webhooks Server
• No → Choose based on direction (inbound = webhooks, outbound = REST API)

Quick Scenarios

Scenario	Solution
Dashboard reading notes	REST API only
Telegram bot saving ideas	Webhooks only
Zapier + dashboard combo	REST API + Webhooks
Updating existing notes from app	REST API only
Receiving emails as notes	Webhooks only
Mobile app modifying drafts	REST API only
RSS feeds creating notes	Webhooks only
Task sync with external manager	REST API only
Multi-device idea capture	Webhooks only

Implementation Considerations

For REST API

Setup complexity: Low (plugin installation only)

Network requirements: Local network access to Obsidian machine; port forwarding if remote

Security: API key authentication, HTTPS with self-signed certs

Reliability: Depends on Obsidian uptime; external app must handle failures

Best practices:

• Use API key rotation
• Restrict network access (firewall rules)
• Implement retry logic in external apps
• Monitor Obsidian availability

For Webhooks Server

Setup complexity: Medium (Docker Compose, PostgreSQL, plugin installation). See the Self-Hosted Setup Guide for a step-by-step walkthrough.

Network requirements: Internet-accessible server (VPS, home server with domain)

Security: Magic links, AES-256-GCM encryption, webhook signature verification

Reliability: Queuing ensures delivery; survives Obsidian restarts

Best practices:

• Run on reliable server (not laptop)
• Set up monitoring (queue depth alerts)
• Backup PostgreSQL database
• Use environment secrets for encryption keys

Getting Started

Try Local REST API Plugin

1. Install from Obsidian Community Plugins: "Local REST API"
2. Enable plugin, set API key in settings
3. Test with curl:

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

4. Build your integration using the API documentation

Best first project: Python script that searches for incomplete tasks and prints them to terminal.

Try Obsidian Webhooks Server

1. Deploy server: GitHub deployment guide
2. Install Obsidian plugin (companion repo)
3. Generate magic link in server admin panel
4. Test with 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. Open Obsidian, see note appear

Best first project: Telegram bot that forwards messages to Obsidian via webhook. For more inspiration, check out How to Receive External Data in Obsidian.

Conclusion

Obsidian Local REST API and Webhooks Server aren't competing solutions — they're tools for different jobs.

Choose REST API when you need to pull data out of Obsidian or modify notes from external apps. It's the right choice for dashboards, mobile apps, and bidirectional sync.

Choose Webhooks when external services need to push data into Obsidian reliably, especially when Obsidian isn't always running. It's perfect for automation platforms, scheduled jobs, and multi-device workflows.

Use both when you have complex integrations with data flowing in both directions.

The good news? You don't have to choose just one. Install both, and build the exact automation architecture your workflow needs.

---

Resources:

• Local REST API Plugin — GitHub repository
• Obsidian Webhooks Server — GitHub repository
• Webhooks Server Landing Page — Documentation and examples

Related reading:

• How Obsidian Webhooks Works — Architecture deep dive
• How to Receive External Data in Obsidian — Complete integration guide
• Self-Hosted Obsidian Webhooks Setup — Docker deployment tutorial