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.

The demo recorder

The demo recorder (@mereon/demo) signs in through this same browser path. demo login opens Mereon, you choose the organization and approve, and the connection is listed under Profile → Connected apps. A personal access token cannot take the place of that sign-in.

Release tokens are a separate credential. An administrator creates one under Settings → Release tokens for a single repository, and CI stores it as MEREON_RELEASE_TOKEN. Only demo release uses it, to publish demos that were held until a deploy. A release token is not a personal access token, and it does not authenticate the rest of the API.

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 unless a connection was granted a write scope. Personal access tokens carry only read. A connection made through the browser sign-in can also be granted content:write (uploads), announcement:write (drafting, sending and withdrawing announcements), training:assign (assigning training and sending pop quizzes), lesson:write (creating and changing lessons), content:manage (editing, publishing, sharing and tagging content, including a video or audio transcript), content:delete (deleting resources from the library), issue:write (filing issues about your knowledge base), public-link:write (sharing a resource with someone who has no account), content-review:write (approving, rejecting, or asking for changes on a content submission), or issue:manage (dismissing, reopening, assigning, merging and resolving issues), or member:manage (inviting people, changing their organization role, deactivating, reactivating and removing them, and setting who they report to), or team:manage (creating, renaming and deleting teams, and changing who is on them), or company-role:manage (creating a company role, saving and publishing a draft of its name or description, moving, merging and deleting it, and choosing who holds it and their standing), or duty:manage (assigning, changing, or removing who is Responsible, Accountable, Consulted, or Informed, including how far a company role’s duty reaches on its advancement path), or curriculum:manage (adding or removing a lesson or a topic on a company role’s training curriculum, including when it is due and whether people who already hold the role must take it), or content-grant:manage (granting or removing a video, an audio file, a document, or a guide that an external company role can read), or topic:retire (retiring a topic the organization no longer follows, and bringing it back), or item:retire (retiring one item the organization no longer follows, and bringing it back), or plan:propose (proposing a plan of changes, which runs only after you approve it in Mereon), or client:create (creating a client organization for a solutions partner), and the consent screen says so before you approve. Even then it can only do what you are permitted to do, checked on every request.

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.