I am now in one month testing phase to decide whether to switch to Recall or not - the write API is a soft breaking point. I have some some Make workflows that are storing info into my current PKM and the unability to do such things in Recall do play against it. All I need is actually to create a new card (e. g. when the workflow decides to store an e-mail for future reference).

Hi team,

I'm a paying user and I've been following the write API since you shipped the read-only API back in April. Since then the answer has always been "coming soon" / "follow up soon" / "further down the line" — but with no date and no endpoints, and the July 12 changelog still describes it as the "first step in development."

Let me explain why this is urgent for me specifically. I want to programmatically create and edit notebook content — including inserting internal [[ ]] links between related cards. I've already run a manual pilot and it works, but it's not viable at scale without a write API. Right now my only option is browser automation, which is slow and fragile.

The minimum that would unblock me: the ability to create/edit notebook content via the API, internal links included. Even if that's all you ship first, it would be huge for me.

Could you share even a realistic date range, or the scope of the first write-API release — will it cover notebook editing and links, or only card creation? Knowing that would help me decide whether to keep waiting or build a workaround.

Thanks for the work you put in — Recall has become central to how I think, which is exactly why I need to get my data out and edit it programmatically.

Miguel

For sure, this is on our radar, we are working towards it. It first requires a couple changes to our our backend, and then this can come right after. Just merging it into the write API request.

I would absolutely love this, being able to use a third-party LLM to generate connections.

Popping a comment to get onboarded to beta test 🫡

Adding my voice to this thread, though from a slightly different angle than most. I use Recall as a , not a second one. My primary loop is podcast notes, YouTube takeaways, and curated web content flowing Recall as a context store for the topics I care about, and then flowing via MCP into Claude (and other agents) whenever I need that context. For me that means write access is genuinely not the top priority — I don't have a constant stream of new synthesis that needs to push back into Recall.

That said, there's one narrow write case that resonates with where Carl Webb is going, just at a smaller scale.

When MCP-Read pulls a specific Recall card into an LLM session and that card actually helps me reach an insight, I'd love to post a tiny feedback marker back to that card — something like Not a full synthesis note, just a lightweight breadcrumb.

The value isn't really for the current session. It's for the MCP read from a sister agent or sister project. The next agent pulling the same card would know it has already been used elsewhere, and what insight it produced. Over time that becomes a Single-Source-of-Truth signal — distinguishing original sources from content that has been recycled three loops around. A small protection against the failure mode of "I keep reading this in agent contexts, therefore it must be true." For my own use, even a minimal POST-a-tag or POST-a-comment endpoint would cover most of what I'd want.

I really love Recall and want to use it as my personal knowledge management memory store and foundation for my "second brain." I need to be able to route things into it FROM the rest of my life (email, Slack, Granola, Zoom recordings, voice notes, Zapier) INTO recall, with each incoming event triggering the autotagging and related processes. Apple "Share" can work if available, but allowing easier accessess for adding content would be a huge plus for me.

Write access is the key to turning Recall into a personal knowledge system. Not interested in CLI/MCP (can open source that myself), just the API. Would open up so many use cases.