Skip to main content
A check is a named set of Markdown instructions: when it applies, what to inspect, what evidence supports a finding, and examples. Global checks are maintained by Effective. Organization checks are shared with members of your tenant. These APIs manage definitions. Creating or editing a check does not start an agent session, review a filing, or create comments. Automated execution is a separate, forthcoming capability. Use an ordinary user API key from the authentication guide. The key identifies your organization. Catalog access does not require a filing ID, a Mission Control, or access to a particular filing. Members can read checks. Tenant Admins can create and edit organization checks; only Effective platform administrators can edit global checks. App, procedure, record-bot, and subject-scoped credentials are not supported for this organization-wide catalog.

​
Find checks

Example 200 response:
The list contains global and organization checks, ordered by ID. limit defaults to 50 and accepts 1–200. For the next page, pass the returned nextCursor as cursor and keep the same limit:
The cursor above is illustrative; use the value from your response. Continue until nextCursor is null. Cursors expire after 24 hours; on 400 invalid_cursor, restart the list without a cursor. This is a live list: concurrent edits may appear on later pages. Read a check for its instructions:
Example 200 response (abbreviated instructions):

​
Create an organization check

Example 201 response:
The response’s Location header identifies the new check. Instructions must contain text and fit within 64 KiB of UTF-8. The complete JSON request must fit within 512 KiB, including escaping; larger requests return 413 request_too_large. Names are fixed when created. Scope is assigned by the server; a customer cannot create a global check. Create does not support idempotency keys. Do not automatically retry if a timeout or connection failure leaves the outcome uncertain. Inspect the catalog and read candidate checks to compare their contents before deciding whether to create again. This is best-effort: names are not unique, and no request identifier reliably links a request to its result. Repeating the request can create a duplicate.

​
Revise instructions

Read the check, then send its versionId as expectedVersionId:
Example 200 response:
Saving replaces the entire Markdown and publishes immediately. Retain the new versionId for the next edit. If the supplied version is no longer current, the API returns 409:
Read the current check, reconcile your changes with its instructions, and retry using its current versionId. After an uncertain PATCH response, first read the check: if it already contains your intended instructions, no further write is needed. Otherwise reconcile before retrying; do not blindly replace another edit. To inspect an earlier revision, pass its version ID:
The returned markdown and versionId identify that revision; updatedAt still describes the check’s latest publication. A version belonging to a different check, or an uploaded version that was never published, returns 404. Store both the check ID and version ID when citing instructions. If versioned storage cannot be read, the API returns 503 temporarily_unavailable with Retry-After in seconds. Retry the same read after that delay.

​
Write useful instructions

Use sections for applicability, instructions, evidence, findings, examples, and sources. Describe state and line-of-business conditions in plain language. Cite authoritative guidance when asserting a regulatory requirement; an example filing alone does not establish one. Missing evidence should result in a request for information, not an assumed pass.