Administration
These endpoints read the organization’s own settings and records: what the organization has told Mereon to treat as true about itself, whether its org chart has been confirmed lately, and what its identity directory has done to its people.
Each is held to the admin page that shows the same data. For findings that is a
narrower rule than the permission the app’s own endpoint checks, which every member
holds, because a token is not a person looking at a screen. The directory
endpoints already ask the app’s own organization.update. Findings and the
directory endpoints both need that permission, which owners, admins and billing
admins have. Anyone else gets 403.
List findings
Section titled “List findings”GET /v1/findings
What the organization has told Mereon to treat as true about itself, newest first. An admin writes some, and the system records others from the organization’s website or a research conversation. The AI features read them as established fact, so this is where to look when an answer assumes something about the organization.
Query parameters
Section titled “Query parameters”| Parameter | Type | Notes |
|---|---|---|
cursor |
string | Pagination cursor from a previous response. |
limit |
number | 1 to 100. Default 50. |
Response
Section titled “Response”{ "data": [ { "id": "fnd_41c9...", "content": "We run three shifts at the Dallas plant.", "source": { "type": "user", "systemSourceType": null }, "createdAt": "2026-09-01T00:00:00.000Z", "updatedAt": "2026-09-02T00:00:00.000Z" } ], "nextCursor": null}source.type is user for a finding an admin wrote and system for one the
system recorded, and then source.systemSourceType says which path:
web_analysis or research_conversation. Who wrote a finding is not returned.
Get whether the org chart is current
Section titled “Get whether the org chart is current”GET /v1/org-chart/verification
Whether an admin has confirmed the org chart recently.
Admins confirm it after onboarding and then every 90 days. It needs the
company-role.read permission, which every role except external has, the same as
the chart itself.
{ "status": "reverification_due", "lastVerifiedAt": "2026-05-01T00:00:00.000Z", "intervalDays": 90, "nextDueAt": "2026-07-30T00:00:00.000Z", "isDue": true}| Field | Type | Notes |
|---|---|---|
status |
string | never_verified, current, or reverification_due. |
lastVerifiedAt |
string | null | When an admin last confirmed the chart, or null if one never has. |
nextDueAt |
string | null | When the next confirmation is due, or null if the chart was never confirmed. |
isDue |
boolean | true when a confirmation is due now, which includes a chart that was never confirmed. |
Who confirmed the chart is not returned.
Get the identity directory connection
Section titled “Get the identity directory connection”GET /v1/directory-sync
The organization’s connection to its identity directory (SCIM): its status, when the directory last authenticated and last changed something, whether it paused itself and why, and how many people it has provisioned, updated, deactivated and skipped.
{ "eligible": true, "connection": { "status": "ACTIVE", "tokenCreatedAt": "2026-01-01T00:00:00.000Z", "tokenLastUsedAt": "2026-09-01T00:00:00.000Z", "tokenExpiresAt": null, "tokenActive": true, "lastSyncAt": "2026-08-30T00:00:00.000Z", "pausedAt": null, "pausedReason": null, "sendWelcomeImmediately": false, "countProvisioned": 120, "countUpdated": 14, "countDeactivated": 6, "countSkipped": 2, "createdAt": "2025-12-01T00:00:00.000Z" }}| Field | Type | Notes |
|---|---|---|
eligible |
boolean | Whether the plan includes directory sync. It is reported and not enforced, so an organization that has lapsed can still read what its directory did. |
connection |
object | null | null when no connection was ever set up. |
connection.status |
string | PENDING, ACTIVE, PAUSED, ERROR, or DISCONNECTED. |
connection.lastSyncAt |
string | null | The last request that changed something, not the last request received. |
connection.pausedAt |
string | null | When sync stopped itself, for a PAUSED connection. |
connection.tokenExpiresAt |
string | null | null means the admin chose no expiry. |
connection.tokenActive |
boolean | Whether the directory holds a credential that can authenticate now: one exists and has not expired. status does not follow it. Revoking the token leaves status as it was, and a token that lapses changes nothing stored, so an ACTIVE connection with tokenActive: false is not syncing. The app shows that as Not connected or Token expired. |
List the directory’s activity
Section titled “List the directory’s activity”GET /v1/directory-sync/events
What the identity directory has done to the organization’s people, newest first: each operation, whether it was applied, skipped, rejected or failed, and why. Use it to answer “why was she not provisioned”.
Query parameters
Section titled “Query parameters”| Parameter | Type | Notes |
|---|---|---|
outcome |
string | APPLIED, SKIPPED, REJECTED, or FAILED. |
cursor |
string | The nextCursor from the previous response. It is opaque, and one that cannot be read is a 400 and not the first page. |
limit |
number | 1 to 100. Default 50. |
Response
Section titled “Response”{ "data": [ { "operation": "CREATE", "outcome": "SKIPPED", "reason": "DOMAIN_MISMATCH", "userName": "sarah@acme.com", "createdAt": "2026-09-01T00:05:00.000Z" } ], "nextCursor": "eyJ0IjoiMjAyNi0w..."}operation is CREATE, UPDATE, DEACTIVATE, REACTIVATE, DELETE, LIST, or
AUTH. reason says why an operation was not applied and is null for one that
was. userName is the address or user name the directory’s request named, even
when no record exists for it.
The sentence the app prints for each event, the directory’s own id for the person
and the employee record are not returned. The sentence is prose with addresses in
it, and its wording is not a contract: several of them say that an account already
uses an address. reason is the stable code for why an operation was not applied,
and is the part to build on.