Obsidian AI API Keys: Connect a Model to Your Notes

Most Obsidian AI plugins work by sending your notes or prompts to an external AI provider using an API key you supply. The plugin handles the interface inside Obsidian; the key tells the provider who is paying for the request. Tools like fenbs let you record which API provider and model your team has approved for a project, so every connected assistant starts with the agreed setup rather than each person choosing independently.

This article covers where to put your API key, which providers work with common Obsidian AI plugins, and how to use alternative endpoints like OpenRouter or DeepSeek.

Where your API key goes in Obsidian

Obsidian AI plugins store API keys in the plugin data folder, which is inside your vault's .obsidian directory. Most plugins show a dedicated field in their settings panel. Paste the key there; the plugin reads it when making requests. The key is stored as a local file on your device.

The main risk is accidental sync. If your vault syncs to a cloud service or a git repository, the .obsidian/plugins folder may sync too. Check your sync settings and confirm the plugin data folder is excluded. A key in a public or shared sync location is effectively exposed.

Which providers Obsidian AI plugins support

Most Obsidian AI plugins support OpenAI out of the box and let you configure a custom API base URL for other providers. OpenAI-compatible endpoints include:

• OpenAI: the default for most plugins; requires an OpenAI API key.
• OpenRouter: a gateway that routes to many models; useful if you want to switch providers without reconfiguring every plugin. See claude-api-key for one way to get a key.
• DeepSeek: an OpenAI-compatible API; use the DeepSeek base URL and a DeepSeek API key.
• Anthropic: some plugins have built-in Anthropic support; others need a plugin that supports non-OpenAI formats.
• Local models via Ollama: supported by plugins that accept a localhost base URL.

Get and configure an API key

Each provider has its own sign-up and key generation process. For OpenAI, you create a key in the API section of your account page. For Anthropic, the same applies through their console. OpenRouter issues keys through its own dashboard and lets you add credit to access multiple providers through one key.

Once you have a key, paste it into the plugin settings under the API key field. If using a custom endpoint, also enter the base URL. Test with a small, non-sensitive note to confirm the connection works before using the plugin on real project material.

Protect your key in practice

An API key that leaks can run up charges on your account before you notice. The standard protections apply: use a key with a usage limit or budget cap if the provider supports one; rotate the key if it ends up in a shared file; use a separate key per project or per tool rather than one master key for everything. codex-api-key covers similar considerations for Codex-based tools.

• Set a monthly budget cap or usage limit in the provider's dashboard.
• Store the key only in plugin settings, not in a note or environment file in the vault.
• Exclude the .obsidian/plugins directory from cloud sync and git.
• Rotate the key if you suspect it has been exposed.

Using OpenRouter for flexibility

OpenRouter is worth considering if you want to switch between models without reconfiguring each plugin. You add one OpenRouter key to a plugin, then choose the model by name in the model field. This makes it easy to compare models or switch when one is unavailable, without managing multiple provider keys across multiple plugins.

The trade-off is that all requests route through OpenRouter's servers. Check their data retention and privacy documentation before routing sensitive vault content through them.

How to do this with fenbs

Record your approved API provider and model in fenbs so every connected assistant starts with the agreed setup, and keep the key itself in the plugin settings where it is safe.

1. Create a free account and add a project for the work your Obsidian notes support.
2. Write a Decision in fenbs recording which provider and model is approved for this project and why. This gives every session a clear starting point without storing the key itself.
3. Add a context note describing which vault folder contains AI-safe notes and which is excluded.
4. Connect a supported AI app to fenbs via Integrations so the approved provider choice is visible to every assistant.
5. When the approved model changes, update the Decision in fenbs so the change reaches every connected session.