API Documentation

Returns a list of findings for your organization.

Required scope: findings:read

Query parameters

Returns a list of assessments for your organization.

Required scope: assessments:read

Query parameters

Returns your organization's remediation tasks, or one task with ?id=. A key whose owner is not an org admin reads only the tasks assigned to them. Each task carries incident_id, the incident it is a corrective action for (null when it is not one), and external_assignee, true when the task is assigned to an invited address with no member account.

Required scope: remediation:read

Query parameters

Read and update evidence metadata (filename, type, size, description, review/expiry dates, version). File contents are never served or writable via the API.

• GET — list evidence metadata (evidence:read).
• PATCH — update metadata by id (evidence:write). Writable: description, review_date, expires_at only.

Query parameters (GET)

Read and manage vendors, including the AI each supplies (ai_involvement), whether it trains on your data (customer_data_training), whether it handles PHI for you (handles_phi: true, false, or null when not recorded; with business_associate_standing yes, possible or no, is_business_associate, and the baa_state: missing, expired, to_confirm, expiring, current or not_needed), its agreements (type baa, dpa or other, with signed and expiry dates), the agreement summary derived from them (has_agreement, agreement_signed_at, agreement_expires_at, all read-only) and review dates. Filter a list by baa. Pass ?id= to GET a single vendor.

• GET — list or fetch vendors (vendors:read).
• POST — create a vendor (vendors:write). Body: name (required), plus optional contact_name, contact_email, website, services_provided, data_access, risk_level, status, handles_phi (true, false or null), ai_involvement, customer_data_training, next_review_date, notes. Returns HTTP 201. Agreements are recorded on the vendor's Agreements tab in the app; a body naming a derived agreement field is refused with 400.
• PATCH — update a vendor by id (vendors:write).

Query parameters (GET)

The Systems register. GET lists systems (filters stage, risk_tier, flag (ai or ephi), generative, q) or fetches one with ?id=, adding its intended use, oversight design and models (ai_systems:read). Every system carries uses_ai and handles_ephi as booleans. POST adds a system (ai_systems:write) with uses_ai (default true) and handles_ephi (default false), at least one true; it counts toward the limit of each flag it holds. A system that uses AI is created in proposed, unclassified; one that does not is created in use (deployed), with no review, and an AI field sent with uses_ai: false is refused. The API never decides: a request carrying risk_tier, eu_ai_act_class, is_gpai, lifecycle_stage or next_review_date is refused. A person sets those on the system's page, and the lifecycle moves only through a review.

Filters take the listed values only; any other value is refused with HTTP 400, naming the allowed values.

AI models (models:read). ?id= returns one model with its recorded versions, the systems it backs and how many evaluation results exist.

Register a new version of a model from a CI or ML pipeline (models:write). Body: model_id, version (required), optional released_on, evaluation_summary, notes. It changes no system's approval; a system that pins a version keeps its pin.

Model evaluation results, one metric per result. GET ?model_id= (optional version_id) lists them newest first, paged with limit (at most 200) and offset (models:read). POST records one (evaluations:write, not granted by default): model_id, version_id, metric, value, optional threshold, passed, dataset, notes, measured_at. Results are append-only, and passed is recorded as sent, never worked out from the threshold.

Published model and system card versions (cards:read). Pass version_id, or system_id / model_id for that subject's latest published card with its content. Drafts are never returned.

AI system reviews and the decisions approvers signed (approvals:read). Filter by system_id or status; ?id= returns one review with its approvers and decisions. Read-only: a decision is signed in the dashboard with a password and a second factor, never through a key.

Filters take the listed values only; any other value is refused with HTTP 400, naming the allowed values.

The risk register. GET lists risks (filters status, category, treatment, ai_system_id) or fetches one with its treating controls (risk_register:read). POST creates a risk (risk_register:write, org admins only) under the same rules as the form: a category is required (an AI trustworthy characteristic, a HIPAA Security Rule section, or the Privacy Rule safeguards), a NIST AI 600-1 category needs a generative system or model, and the residual pair is both or neither. Unrated residual values are null, never zero.

Filters take the listed values only; any other value is refused with HTTP 400, naming the allowed values.

The dataset register (datasets:read): each dataset's source, terms, whether a person recorded that it holds personal data, and its known limitations. Filter by status, source_type, personal_data or q; ?id= returns one dataset with the systems and models that use it, each in its role. Read-only.

Filters take the listed values only; any other value is refused with HTTP 400, naming the allowed values.

Each AI system's AI impact assessment and fundamental rights impact assessment, as the register shows them (impact_assessments:read). Filter by aiia or fria (none, draft, published, due) or q. Pass version_id (or id, the same value), or system_id and kind (aiia or fria) for that system's latest published version with its sections and how it was signed; naming a version beside a system or kind is refused. Published versions only: a draft's text is never returned, and versions are approved in the dashboard with a password and a second factor.

Management reviews of the AI governance program (management_reviews:read), drafts and finalized, filtered by status or q (every review's title, and the minutes and decisions of finalized reviews only). ?id= returns a finalized review with its minutes, decisions, actions and the program's numbers as they stood when it was finalized; a draft review is not returned. Read-only.

The human oversight roster (oversight:read): who is assigned which oversight capability on each AI system, whether they are still an active member who can act, and the date each was briefed on automation bias (automation_bias_briefed_on, null when not recorded). Lists today's current assignments unless state (current, scheduled, ended, all) says otherwise; filter by system_id or capability. Read-only.

Monitoring plans (monitoring_plans:read): every AI system in the inventory with where its plan stands (state: none, draft, published), its latest published version, when the plan was last confirmed current, whether its review is due (by the review frequency of the published version in force), whether the draft has changes that are not published, and plan_gap (a deployed system recorded as high-risk with no published plan). ?id= returns one published version, or ?system_id= that system's latest: what is monitored and why, the data sources, thresholds and escalation, responsibilities, how findings reach incidents and re-review, the review frequency, and the metrics and oversight roster as they stood when it was published. A draft's text is not returned. Read-only.

Bias audits (bias_audits:read): the bias audits recorded for your AI systems under New York City Local Law 144, newest first, filtered by system_id, method and data_source: each audit's date, the date the next is due and its state (current, due_soon, overdue), the auditor and whether independence is recorded, the method, the data used, the categories calculated, the count of people in an unknown category (null when not recorded), the published summary and what the record leaves out (gaps). ?id= adds, for an admin or an auditor, the test-data explanation and notes. Read-only.

Requests from people affected by an AI-assisted decision (person_requests:read). An admin's or auditor's key reads every request; any other member's key reads the requests they handle or review. Filter by status, request_type, legal_basis, ai_system_id, overdue=1 or q; ?id= adds the summary and the response. The requester's name and contact are never returned through the API: the requester reference identifies the request. Read-only.

Manage the delivered-training employee roster — built for HR-system sync. Employees are keyed by email (unique per organization), so re-posting a person updates them and never duplicates. Course assignment and invite emails stay in the dashboard.

• GET — list the roster, ?id= for one employee, ?active=1 for active only (training:read).
• POST — upsert by email (training:write). Body: full_name (required), email (required), optional department and ai_roles, a list drawn from builder, reviewer (approvers) and executive (leadership); everyone takes AI literacy and each role adds its own course. Returns HTTP 201 when created, 200 when an existing email was updated.
• PATCH — update by id: full_name, department, is_active (training:write). Deactivation excludes the employee from bulk assignment while preserving history.
• DELETE — remove by ?id= (training:write). Employees with completed training cannot be deleted (HTTP 409) — completions are compliance evidence; deactivate instead.

Read-only delivered-training report (training:read): every assignment with its effective status (expired once a pass is older than the 12-month validity window), score, attempts, duration, valid-through date, reminder count, invite-failure flag, and certificate id, plus an org-level stats block. Filters: course_key, status, employee_id; paginate with limit/offset. Assigning, resending, and revoking are dashboard-only actions (they send email).

The complete merged training transcript (training:read) — both delivered employee training and legacy manually-logged completions, the same dataset as the dashboard transcript export. One call gives an auditor or HR system the organization's full training record. Filters: q (person name/email), source (delivered|logged), status; paginate with limit (max 200) / offset. Every pull is recorded in the audit log.

Manage your organization's outbound webhook endpoints.

• GET — list endpoints (webhooks:read). Append ?catalog=1 for the list of subscribable event names. Signing secrets are never returned on read.
• POST — create an endpoint (webhooks:write). Body: url, events (array), optional description. The signing secret is returned once in the response.
• PATCH — update url / events / description / is_active by id (webhooks:write).
• DELETE — remove an endpoint by id (webhooks:write).

Webhook URLs are validated against an SSRF guard. Use the X-HTTP-Method-Override header if your client can't send PATCH/DELETE.

Returns your organization's incidents: type, severity, the AI system and model involved, whether personal data was involved, the answers to whether protected health information and a system that uses AI were involved (phi_involved, ai_involved, ai_serious; null for an incident logged before the questions), people affected (null when not yet known), and whether the incident is serious and when an authority was notified. Pass ?id= for a single incident. POST creates one (incidents:write) with title, discovery_date and optional incident_type, severity, ai_system_id, ai_model_id, description, personal_data_involved, people_affected, serious_incident, phi_involved (yes, no, unknown), ai_involved (yes, no) and ai_serious (yes, no, unknown; when recorded it decides serious_incident, and ai_involved: no records it as not serious). A new incident starts open; move it on in the dashboard once it has been triaged.

Required scope: incidents:read

Query parameters

Returns policies with status, version, owner, and review dates. Pass ?id= for a single policy.

Required scope: policies:read

Query parameters

Returns your organization's tamper-evident audit log, newest first — the same event stream that drives webhooks and SIEM export. Ideal for pulling activity into your own SIEM/GRC tooling.

Required scope: audit:read

Query parameters

Returns your organization's compliance scores, one per assessment family and never blended: the top-level score (0–100), letter grade and per-dimension breakdown are the AI governance score (Findings, Policies & Docs, Training, Incident Response), and scores lists every family you are scored in — the HIPAA score too once you have a HIPAA assessment — each with its own dimensions and the date of its last daily snapshot.

Required scope: compliance:read