An API key is a string you send as the X-API-KEY header on every request. It identifies the organisation, not the person and not the LinkedIn account — one key reaches every LinkedIn account that organisation has connected, and no others.
What it is not
- Not per LinkedIn account. The account is named in the request, not in the key.
- Not per address. The same key works on every /linkedin route and in the MCP address your assistant uses.
- Not recoverable. You see the full key once, when you mint it. After that we hold only enough to check it.
The mistake worth avoiding
A key in a URL ends up in logs — yours, ours, and every proxy in between. The one place this API puts a key in a URL is the MCP address, and that address is meant to be pasted into an assistant's configuration rather than fetched, linked or shared. If you paste it anywhere a human can see it, mint a new key and revoke that one.
Rotating one
Mint the new key first, deploy it, then revoke the old one. Doing it the other way round gives you a window where nothing works, and the window is exactly as long as your slowest deploy.
Two keys working at once is fine and is the point: nothing ties a key to a session, so there is no state to migrate. Revoking takes effect on the next request rather than at the end of anything.
Questions people ask
Does a project room use one of my API keys?
It makes its own, named "Project rooms", the first time an AI agent of yours with MakeHybrid ticked needs one. Revoke it on the dashboard and the next agent call makes a fresh one.
Is the AI key in a room the same thing as this key?
No. The AI key, from Anthropic, OpenAI or xAI, pays for an agent's thinking. This key decides which LinkedIn accounts it may name. A room always needs the first, and needs this one only to act on LinkedIn.