The REST API is available on every plan, including the free tier, as is
SSO (SAML 2.0).
The REST API at /api/v1/ lets external tools read and update your compliance data. Authenticate with a Bearer API key:
Authorization: Bearer ohk_...A key records whether the session that created it had completed multi-factor authentication. If your organization requires MFA (Settings → Users → MFA policy), keys created from a session without a second factor are refused with 403 until you create a new key from an MFA-verified session — the same rule that applies to browser sessions and to MCP connections.
Keys carry explicit scopes. Read scopes (findings:read, assessments:read, remediation:read) gate GET; write scopes (*:write) gate POST/PATCH. Grant only what an integration needs, and set an expiry on write-capable keys.
A scope is necessary but not sufficient, on reads as well as writes. A scope answers "may this key touch findings at all"; it never answers "may this PERSON".
Every call is checked against the key owner's current role, and the check mirrors the corresponding screen in the app: if the owner cannot open a register in the dashboard, their key cannot read it through the API either. So a key owned by a contributor is refused the audit log, the incident register, webhooks, the compliance score and the training endpoints; a key owned by a read-only auditor is refused the remediation register outright, and is refused findings, policies, evidence, assessments and scans unless their auditor grant covers that scope. Findings and remediation are also row-scoped the same way the screens are: a contributor's key returns only records assigned to them.
Writes add two further requirements: the owner must hold an organization-admin role (for assessments and remediation, any non-auditor role), and your organization must have an executed Business Associate Agreement.
Point integrations at a key owned by an organization admin. A key inherits its owner's current role, so moving that person to auditor or contributor narrows what the key can do — reads included.
If any call returns 403 where you expect 200, check the key owner's role, the key's scopes, and your BAA status before regenerating the key. Regenerating does not change what a key is permitted to do.
GET /api/v1/{findings,assessments,remediation} — list with filters + paging (?limit= 1–100, ?offset=).GET /api/v1/{evidence,vendors} — read evidence metadata (never file contents) and vendors/BAAs.GET /api/v1/webhooks — list endpoints; ?catalog=1 lists subscribable events.POST /api/v1/remediation — create a task (returns 201).PATCH /api/v1/{findings,remediation,assessments} — update by id.POST/PATCH/DELETE /api/v1/webhooks — manage webhook endpoints.Findings and assessments are update-only via the API (findings are generated from assessments; assessments need question/scope setup done in the app).
scans:read / scans:write)Requires the network-scan module (enable it under Settings → Organization → Features). Lets you request scans, pull results, download reports, and manage recurring schedules.
GET /api/v1/scans — list scans (?status=, ?limit= ≤200), or ?id=<uuid> for one scan plus its full retest chain and severity counts.POST /api/v1/scans — request an automated scan. Body: either targets: [{type: ip|cidr|url, value}] or from_systems: true (collect from your ePHI systems), optional assessment_id. Targets are SSRF-validated; private/reserved/malformed are rejected 422 and listed in the response's dropped. Returns 202 with the new scan id. 429 if you're at the concurrency limit.DELETE /api/v1/scans?id=<uuid> — cancel an in-flight scan (409 if it's already finished).GET /api/v1/scan-report?id=<uuid> — download the completed scan's report file (streamed bytes, not JSON). 404 until a report exists.GET/POST/PATCH/DELETE /api/v1/scan-schedules — manage recurring scans. Create with frequency (daily|weekly|monthly — daily is the tightest) and window_start_hour (0–23, the start of a 4-hour launch window).See the Network Vulnerability Scanning help page for scope best-practices and the retest workflow, and openapi.yaml for full request/response schemas.
Responses are JSON with a data array plus count/limit/offset (findings and remediation also include total). Errors return a non-2xx status with a single error key; an unhandled 500 additionally carries message and request_id. Keys are rate-limited to 100 requests/minute (see the X-RateLimit-* response headers). The API is on every plan; create and scope keys in Settings → API.
MCP (Model Context Protocol) lets an AI harness — Claude Desktop, Claude Code, or any MCP client — read your compliance data, and, only if you switch it on, update a few records.
The server URL is:
https://prusikhealth.com/api/mcpThere is no key to paste. The client discovers the server, registers itself, and sends you through Prusik Health login and a consent screen; it then receives a short-lived token bound to your account and your permissions. Revoke it at any time under Settings → API.
Prusik Health) and paste the server URL above.claude mcp add --transport http prusik-health https://prusikhealth.com/api/mcpThen run /mcp inside Claude Code and choose Authenticate. The same login and consent screen opens in your browser. claude mcp list shows the connection.
Any client supporting remote MCP over HTTP with OAuth 2.1 works. Point it at the server URL; it discovers everything else from /.well-known/oauth-protected-resource. Clients that only speak stdio need a remote-MCP bridge.
Findings, assessments, policies, remediation tasks, vendors and BAAs, security incidents, evidence metadata, the risk register, training records, your compliance score, and the audit log.
The assistant always acts with your own permissions — never more than you can see in the app yourself. If you cannot open a register in the dashboard, the assistant cannot read it either. Every call is recorded in the audit log — including calls that are refused.
A connected assistant can read your data. It can only change data — update findings, create remediation tasks, add comments — when both of these are true:
Turning write access back off takes effect immediately, including for connections that already hold write scope. Write actions still prompt you to confirm in the MCP client.
Enable it only if your agreement with the AI client's provider covers sending compliance data to that provider. Free-text fields — incident narratives, finding notes, evidence — may contain PHI.
A superadmin can additionally work across organizations:
platform_orgs and platform_posture return every organization on the platform with its plan, status, compliance score and finding, incident and task counts. These are aggregates only — no notes, narratives or evidence ever cross a tenant boundary this way. The scope is requested explicitly and is named on the consent screen; it is never granted by default.org_id on any ordinary tool acts on one named organization instead of your own, with full detail. One organization per call, so no single response mixes two tenants' records. If the connection was also granted write scope, org_id applies to the write tools too — so it can update findings, create tasks and add comments in another organization, not only read them.Both are refused for everyone else: a non-superadmin passing org_id simply reads their own organization, and the platform tools are not offered at all.
See web/docs/CONTRACT-mcp.md for the full security model.