Authentication

There are two ways to authenticate with the Mereon API and MCP server, and they resolve to the same thing: your own live access in Mereon.

• Connect by signing in. Interactive AI tools, like Claude Code or Cursor, send you through a Mereon sign-in and a consent step. There is no token to copy, and multi-factor authentication is enforced. This is the recommended path for any tool that can open a browser.
• Personal access token (PAT). A long-lived key you paste into a script or CI job, sent as a header. This is the path for headless use, where there is no browser to sign in with.

Both resolve every request to the person behind the credential and check that person’s current access live, so neither can read anything you cannot.

Connect by signing in

When an interactive client connects, it opens Mereon in your browser. You sign in the way you normally sign in to the app, complete multi-factor authentication if your account uses it, choose which organization the connection may read, and approve. The client then receives access automatically, with nothing for you to copy or store.

The connection it creates is short-lived and refreshes itself in the background, so you stay connected without managing a credential. It is pinned to the single organization you chose at the consent step.

Manage your connections under Profile → Connected apps in the Mereon app. Each one shows the tool, the organization it can read, and when it was last used, and you can revoke any of them to cut off its access.

Tip

Signing in enforces multi-factor authentication, where a pasted token does not, so prefer it for any tool that can open a browser. See Connect Claude Code for the one-command setup.

Personal access tokens

For scripts, CI jobs, and any tool that cannot run a browser sign-in, create a personal access token under Profile → API Tokens in the Mereon app. The full value is shown once, at creation, and never again. Copy it then.

A token looks like this:

mrn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Send it on every request as a bearer token:

curl https://api.mereon.ai/v1/me \
  -H "Authorization: Bearer mrn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Connections and tokens see what you see

A connection or token is not a separate identity with its own permissions. It resolves to the person who set it up, and every request is evaluated against that person’s current access in Mereon, live.

This has a few practical consequences:

• If your access to some content is removed, your connections and tokens lose access to it on the very next request. Nothing is cached.
• A credential never grants more than the person already has. It cannot see content they cannot see.
• Access is read-only. Credentials carry the read scope and there are no endpoints that change your data.

Pinned to one organization

If you belong to more than one organization, a credential always resolves to a single organization, even if you later switch your active organization in the app. A connection is pinned to the organization you pick at the consent step; a token is pinned to the organization that was active when you created it. To use another organization, connect again (or create another token) for it.

Expiry and refresh

A connection’s access refreshes itself automatically as long as you keep using it, and stops once you revoke it. There is nothing to rotate.

Personal access tokens expire after 90 days by default. The expiry is set when the token is created and does not change afterward, so rotating a token means creating a new one and deleting the old. Your organization’s admins can change the default expiry policy, including allowing non-expiring tokens. The policy applies to newly created tokens; existing tokens keep the expiry they were issued with.

What your admins control

Organization admins have organization-wide controls over API access:

• Turn API access on or off for the whole organization. When it is off, no one can connect a new tool, create a token, or use an existing one.
• Set the expiry policy that applies to new tokens.
• List and revoke any member’s tokens and any member’s connections.
• The organization’s subscription must include the public API feature. Plan dependent If you cannot see the API Tokens or Connected apps screens, ask your admin whether your plan includes it.

Keeping credentials safe

Caution

A personal access token bypasses multi-factor authentication at request time, because it is a long-lived credential. Signing in to connect does not, so prefer it where you can. When you do use a token:

• Store it in a secrets manager or environment variable, never in committed code or shared chat.
• Create one token per tool or machine, so you can revoke a single one without disrupting the rest.
• Revoke tokens you no longer use from Profile → API Tokens, and connections from Profile → Connected apps.

Auditing

Every successful request is recorded against the connection or token, including the endpoint or MCP tool that was called. An admin can review the history to answer questions like “what did this tool read last week?” Connecting and revoking are recorded too, so admins can see when a tool was connected and when its access was cut off. Denied and failed requests are not recorded.