Permissions & content scope

The single most important thing to understand about the Mereon API: a connection sees exactly what the person behind it can see, and nothing more.

Resolved live, every request

A token is not a separate identity with its own permission set. It resolves to the user who created it, and each request is evaluated against that user’s current access in Mereon at the moment of the call. Permissions are never snapshotted into the token.

So:

• Grant the user access to more content, and their tokens can read it on the next request.
• Remove their access, and their tokens lose it immediately. No cache to expire, no token to rotate.
• A token can never read content its owner cannot read.

What “scope” filters

Endpoints that return knowledge (topics, items, evidence, duties, issues) and content are filtered to the caller’s visible scope. Two people in the same organization with different access will get different results from the same request, and that is expected.

Some endpoints are inherently personal. For example, assignedToMe on the issues endpoint filters to issues assigned to the connected user.

Read-only by design

The public API and MCP server contain no operations that change your data. Every token carries the read scope, and there are no write endpoints. A POST request (such as POST /v1/search) is still a read; it exists only to accept long queries in a request body.

Multiple organizations

A token is pinned to the organization it was created in. If you work across organizations, create one token per organization. See Authentication for details.