How to create plugin APIs for other plugins to use | plugin-to-plugin communication

Hey everyone,

I’m working on a new Obsidian plugin, Plugin A, and I’m trying to leverage some features from another plugin, Plugin B.

I’m thinking of a scenario where Plugin A can call a specific function or API in Plugin B, passing some data as input. Then, Plugin B would handle the rest of the processing.

I’m curious if anyone has experience with this kind of plugin-to-plugin communication. Has anyone implemented a similar setup where one plugin exposes an API for another plugin to use?

The easiest way I can think of is Plugin A will write something inside LocalStorage and that will trigger one event for Plugin-B to check the updated data and then execute the process. But I don’t think anyone must have done that, or for sure it won’t be an approach to go for at all.

I’d really appreciate any insights, code examples, or suggestions on how to achieve this. Thanks in advance!

1 Like

As of now, surfing, found the following plugin, which is exposing its APIs for other plugins to use : Obsidian-TTS

Turn out, someone has already created a node package for plugin-to-plugin communication : @vanakat/plugin-api

And the API from Obsidian-TTS has been used in the following plugin : Obsidian-pdf-plus
But, i don’t think the PDF plus plugin is making use of that node package. I think it’s directly using the APIs.

Is this a way we are supposed to use plugin APIs ?

Also, will be safe to use the node package, I saw it has been updated last month ?

@Tu2_atmanand considering that the author of Obsidian-TTS is one of Obsidian developers, I think it is quite safe to use the approach he uses

1 Like

Yeah, that’s a good point. Will try using the node package method, for creating, as well as using plugin APIs.

I’m the PDF++ dev. If I remember correctly, first I tried to use the API registered with @vanakat/plugin-api, but I chose not to because the API lacked some methods that README said it had. It also didn’t have any typing, and the API documentation was giving 404. As a result, I had to resort to the temporary solution of using the plugin’s internal method directly. It is obviously undesirable, but using the API seemed to be almost equally unreliable.

1 Like

Make sense, but still accessing plugin APIs using a brute force method doesn’t seem to be a good idea, besides, if the functions are placed in different files other than main.ts, then it will require too much work-around to access those functions.

On the @vanakat/plugin-api readme, the developer has given examples, where the famous Zotero plugin is making use of the package. By referring to it, might find some useful coding practices to inculcate. Still not sure, havent gone through it much.