I would love to see a Read only API for the official sync plugin.
I have ideas for two ways to use it already:
Would love to have something similar to this, though not necessarily an API.
I vastly prefer Obsidian Sync over rolling my own sync, however, there are lots of use-cases where I want to make a change to a file stored in Obsidian from a computer (e.g. Raspberry Pi) that would not be running a full copy of Obsidian.
E.g. I have a Raspberry PI with an NFC reader that when tapped should mark a task on my daily page as done. The code to edit the file to make this change is super simple but getting the file out of and into Obsidian with Obsidian sync is not.
I’d love if Obsidian shipped with a stripped down executable that helped users do something like this:
obsidian init foobar ~/foobar (goes through login/encryption flow, and downloads the vault to the current state)obsidian sync foobar.This would make so many cool workflows possible that right now are not possible if you want to use Obsidian Sync. It is extremely useful for both getting data into and out of Obsidian outside of the desktop environment. Since part of the power of Obsidian is that it’s primarily “just files” there are so many things that could be accomplished by things outside of Obsidian that know how to read, write, and modify files.
I definitely understand that this is probably low on the totem pole of requests but given how amazing Obsidian’s plugin API and surrounding ecosystem is, I’m extremely surprised[0] that something like this (in some fashion) wouldn’t be something worth pursuing or helping the community to pursue.
[0] I know that I’m missing a lot of things that probably make this request non-trivial – however I would love to believe that there’s a boiled down requirement set that could both satisfy a lot of folks as well as not be a super heavy lift.
Additionally, being a stripped down binary, hopefully utilizing the same code that’s in Obsidian Sync, and shipped with Obsidian itself would hopefully take care of the majority of issues raised in the previously linked thread:
we purposefully don’t have APIs published and discourage third party sync clients, because we are unable to quality control and prevent undefined behavior when third party sync clients misbehave. It’s easy to get the encryption details wrong and end up with corrupted or deleted files, introduce errors to the sync process and interrupting sync for the Sync plugin, or possibly trigger infinite loops that overflows the user’s storage, or worse, causes an unintended DoS attack on the sync server.
Use case or problem
I would like Obsidian Sync to expose an official, authenticated API that allows programmatic read/write access to a vault.
My primary use case is to integrate Obsidian Sync with external automation systems such as GitHub Actions, CI pipelines, or other scheduled workflows.
For example:
• Automatically generating or updating notes (daily digests, summaries, reminders, research outputs) from external tools.
• Writing structured content into the vault without requiring the Obsidian app to be open.
• Pushing updates that will later be synced and visible on mobile devices when the app is opened, effectively acting as a “background push” mechanism.At the moment, Obsidian Sync is tightly coupled to the client apps. This makes it difficult to integrate Obsidian into modern automation and agent-based workflows, even though Obsidian itself is often used as a central personal knowledge system.
⸻
Proposed solution
Provide an official Obsidian Sync API with secure authentication (e.g. token-based or scoped keys) that allows limited, explicit operations such as:
• Create / update / delete markdown files
• Append content to existing notes
• Read file metadata or content (optionally read-only scopes)
• Trigger a sync or queue changes for the next client syncThis API could be scoped strictly to Obsidian Sync vaults and designed with safety limits (rate limits, permission scopes, opt-in per vault).
Such an API would:
• Enable first-class automation while preserving Obsidian Sync as the source of truth
• Avoid fragile filesystem hacks or unofficial reverse-engineering
• Open the door for integrations with GitHub Actions, cron jobs, LLM agents, and other tooling
• Strengthen Obsidian’s position as an automation-friendly knowledge platform, not just a local editor⸻
Current workaround (optional)
Current workarounds include:
• Using third-party sync solutions (Git, WebDAV, cloud drives) instead of Obsidian Sync
• Running a self-hosted Obsidian instance or file server
• Writing directly to a synced folder on a specific machineThese approaches either reduce reliability on mobile, introduce security risks, or defeat the purpose of using Obsidian Sync in the first place.
⸻
Related feature requests (optional)
• Developer API extensions
• Automation / programmatic access to vaults
• Server-side sync hooks or webhooks(Links can be added here if relevant threads exist.)
+100 to this request. I currently pay for Obsidian Sync, mostly to support the team, for functionality pretty close to what I would get with the various cloud storage solutions I’m paying for.
I’d like at least a minimum of the connectivity functionality I have in those file systems, like being able to create new notes or edit existing ones via webhooks.
Please please ship something like this 
I AM NOT A FAN OF THIS IN ANY WAY, SHAPE, OR FORM.
I pay for Obsidian Sync because it is secure and it works way better than any of the other sync services (provided it is setup properly - iCloud, G Drive, Onedrive, and Dropbox… are not your friends when using Obsidian Sync).
You can get at blocks and tags and most any content in your vault via the standard API on your LOCAL vault. Even the core search plugin allows for all of this and there are numerous ways to automate that. And, since most of you asking for this are developers, create your own private plugin to do what your are requesting.
THERE IS A REASON WHY THIS WILL NEVER BE DONE - and if it is, most of us would stop using Obsidian Sync immediately and be way more LOUDER about it than the few of you in this post.
Making a public interface to secure sync service… are you folks aware of what you’re asking for in this post?
Tangentially related to this thread, we recently introduced a BETA version of headless sync client.