Bring your own AI. Automate your casework.
Connect a local AI assistant, build a custom workflow, or integrate your own software. The REST API and MCP server expose 140 application operations using the same account permissions and usage limits as the website.
Upload & organize
Add evidence and documents, create and move folders, edit descriptions, apply labels, and assign categories.
Prepare & collaborate
Manage cases, messages, hearings, contacts, tasks, preparation, sharing, and exports.
Stay in control
Create named tokens, select permissions, set an expiration or leave it open-ended, and revoke access at any time.
Give your AI the integration skill
Download a reusable skill with MCP setup instructions, casework guidance, and the local adapter for CourtBriefly and Custody Commander.
Download AI skill (.zip) · Installation and connection guide
Make your first request
- Sign in and open API tokens.
- Create a token with the permissions your integration needs. The “API token created” modal shows the full token with a Copy token button. Save it before closing; it is shown only once. The token list only shows a prefix. If you lose the full token, revoke it and create a replacement.
- Set your app URL and token as environment variables, then request your default case:
export CASE_COMMANDER_URL="https://app.courtbriefly.com" # Set CASE_COMMANDER_API_TOKEN securely in your environment. curl "$CASE_COMMANDER_URL/api/v1/case" \ -H "Authorization: Bearer $CASE_COMMANDER_API_TOKEN"
This request requires case:read. Use the returned case ID in subsequent operations. Both app.courtbriefly.com and app.custodycommander.com support the API.
Upload, move, label
A token with evidence:write can upload a file and update its labels and folder:
curl "$CASE_COMMANDER_URL/api/v1/evidence" \
-H "Authorization: Bearer $CASE_COMMANDER_API_TOKEN" \
-F "caseId=YOUR_CASE_ID" -F "files=@./receipt.pdf"
curl -X PATCH "$CASE_COMMANDER_URL/api/v1/evidence/YOUR_EVIDENCE_ID" \
-H "Authorization: Bearer $CASE_COMMANDER_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"folderId":"YOUR_FOLDER_ID","tagNames":["expenses"],"description":"School receipt"}'Use folders:write to create folders and issues:write to manage categories. Assign category IDs with issueIds; assign cases and hearings with courtCaseIds and hearingIds. Setting folderId to null moves an item out of its folder. Audio/video uploads require the same recording-consent field as the site. See Swagger for operation details.
Permissions, contexts, and limits
- Permissions are selected by area and action:
evidence:read,evidence:write,documents:read, and more. Write access can include deletion. Full access (*) includes every present and future operation the account is authorized to use. - A token never grants access to another person’s private data or bypasses sharing, firm roles, archived-matter restrictions, paid features, storage limits, or AI allowances. Read permissions may return related data visible in that area of the app. Export permissions permit the corresponding exports.
- API and MCP share 120 requests per minute per account across all tokens and server instances. A 429 response includes
Retry-After. Existing app-specific limits also apply. - Local AI reasoning does not consume the app’s AI allowance. Calling an app AI extraction, analysis, drafting, transcription, mediation, or assistant operation uses its existing billing rules. The app meters AI operations and records provider tokens; integration tokens are credentials, not additional AI credits.
- Pass
X-Case-Context: ws:WORKSPACE_IDormatter:CASE_IDfor an explicit context. Access is validated. With no header, contextual operations use your default workspace. ExplicitcaseIdparameters select a case independently and still undergo access checks. A context header selects a view; it does not restrict a token to that workspace. - API requests are stateless. Workspace switching returns an
activecontext value; send it on later requests. Cookies are not used for API authentication. - 400 means invalid input, 401 means missing/invalid/expired/revoked credentials, 402 means a plan or usage limit, 403 means insufficient permission, and 404 means an unavailable resource. Do not automatically retry mutations after a timeout: first check whether the action completed.
Request and document limits
The website and REST API accept at most 32 MiB per multipart request, 25 MiB per file, and 30 files. JSON bodies are limited to 4 MiB. MCP additionally limits the encoded request to 24 MiB and each decoded file to 16 MiB. Document extraction runs in isolated workers with a 15-second deadline, a 128 MiB V8 old-generation budget, at most 64 MiB of archive expansion, 2,000 archive entries, 500 PDF pages, and 2 million extracted characters. Split larger uploads into smaller requests. A 413 response means a request or processing limit was exceeded; a 429 response means processors are busy. These limits supplement existing plan, storage, permission and AI limits.
Cookie-authenticated writes require a same-origin Origin or Referer. API/MCP bearer authentication is checked independently and does not require browser cookies. Client-supplied middleware path, method and identity headers never establish authority.
Authenticator setup
POST /api/v1/account/security with {"action":"setup","password":"CURRENT_PASSWORD"}, or call MCP tool post_account_security with the same JSON body. Requires account:write. The response includes a manual secret and an otpauth:// uri. Render the URI as a QR code locally, as the security page does; never send it to an external QR service or log it. Apple Passwords and other TOTP authenticator apps can scan it or use the manual key. Setup expires after ten minutes. Complete setup with action: "enable", the current password, and the generated code; save the returned single-use recovery codes immediately.
All application operations, one interface
The Swagger reference and MCP tools share the same operation catalog. Account security operations still require password/MFA confirmation where the site does. Current terms and explicit acceptance are available through GET and POST /account/terms; integrations must present the terms and obtain the user’s acceptance before recording consent. The built-in assistant requires full access because it can perform actions across areas. Signup, password reset, browser login/logout, anonymous analytics, and payment-provider callbacks retain their dedicated authentication flows; they are not personal-token operations.
Existing tokens with specific permissions keep those permissions as features grow. Full-access tokens also cover new features. Regenerate your integration from the OpenAPI document when upgrading clients.
AI model
All text and image AI features use xAI Grok 4.7 (grok-4.7), including assistant chat, drafting, message analysis, evidence extraction and mediation. The website, versioned API and MCP use the same service, permissions and usage limits. Speech transcription and voice synthesis use their dedicated audio providers. Provider credentials remain server-side.
Assistant actions and document history
The assistant carries out explicitly requested edits without a second approval. Before reading sources, it identifies allowed actions, changed fields and target records from user requests, using previous user messages only to resolve follow-up details. Retrieved content cannot add permissions. Name records in edit requests; missing or ambiguous targets require clarification. Source-derived factual accuracy still needs review. The assistant cannot attest to verified facts or filing completion.
Deleting a document or evidence item creates a ten-minute confirmation proposal. The built-in assistant cannot confirm it. API/MCP clients use POST /api/v1/assistant/deletions (caseId, kind, id), present the returned label, and call POST /api/v1/assistant/deletions/PROPOSAL_ID/confirm with {"confirmed":true} only after the user confirms. Both operations require full-access token scope, existing edit permission, and a writable matter. Confirmation is single-use and rejects changed assets. Direct asset DELETE endpoints retain their existing semantics; external integrations remain responsible for obtaining user confirmation.
Document title, body and record-note changes automatically save the previous text, including assistant edits and re-extraction. History begins with edits made after this release. GET /api/v1/documents/DOCUMENT_ID/versions lists previous versions; pass versionId to read one snapshot or before=nextCursor for older pages. POST to the same path with versionId and expectedUpdatedAt restores a version and saves the displaced text. A 409 means the document changed: reload before retrying. PATCH /documents also accepts expectedUpdatedAt for conflict protection. Restoring preserves attachments/sharing and clears signatures and review. Historical text requires edit permission, even for GET, and consumes the existing matter payer’s storage quota. Versions are removed when their document is deleted.
MCP tools: get_documents_by_id_versions, post_documents_by_id_versions, post_assistant_deletions, and post_assistant_deletions_by_id_confirm. Use documents:read for history reads and documents:write for restore, in addition to document edit permission. Chat responses contain pendingDeletions for confirmation controls; never pass these controls back into model context as approvals.
Case workspaces and case context
The website groups Evidence, Binders, Preparation, To Dos, Timeline and Documents under /cases/COURT_CASE_ID. The API still uses caseId for the parent workspace and courtCaseId for one court file. Discover court files with GET /api/v1/court-cases?caseId=WORKSPACE_ID or MCP get_court_cases. Pass courtCaseId to evidence, documents, to-do and timeline list/create operations to match the case view. Assign evidence to several cases with PATCH /api/v1/evidence/ID and courtCaseIds; this preserves one original.
Message import accepts multipart courtCaseId. Message lists, threads, conversation search and message-log exports accept it as a query parameter; thread rename/delete, bulk operations and analysis accept it in the JSON body. This keeps identical participants in separate cases isolated for those operations. Omit the parameter for the full workspace, including older unassigned messages. The same fields are exposed by the corresponding MCP tools, including post_messages_import, get_messages_threads and post_messages_analyze. Case assignment is checked against accessible court files; existing message permissions, attestation, storage limits, export entitlements and AI metering continue to apply.
Preparation and binder records retain their courtCaseId in the existing preparation service. Filter returned collections by that field; evidence options expose courtCases and message options expose courtCaseId. For a scoped task import, POST preparation with the current revision and {"type":"import-todos","courtCaseId":"COURT_CASE_ID"} as the action. Backups remain workspace-wide. Assistant chat accepts optional courtCaseId as current-case context; full-access token scope and every existing mutation check remain required.
Sharing and account tabs reorganize existing operations: sharing/inbox, account/security, account, billing/status, billing/portal and AI usage. Global To Dos and Timeline remain available without courtCaseId. Case navigation does not change token scopes or account permissions.
Timeline filters
The timeline supports independent multi-select pills for years, months, and entry types. GET /api/v1/timeline and MCP tool get_timeline accept the same comma-separated query filters: kinds (event, evidence, keydate, hearing), years (four-digit years), and months (01–12). Values within a filter use OR; filters combine with AND. Omitted filters show all values; an empty string selects none. Invalid values return 400. Existing case permissions and the timeline:read scope apply.
{
"query": {
"caseId": "YOUR_CASE_ID",
"kinds": "event,hearing",
"years": "2025,2026",
"months": "01,09"
}
}Pass this query object to MCP get_timeline, or use its fields as URL query parameters for the versioned API.
Timeline formatting
Timeline titles and details support Markdown, including headings, bold, italic, strikethrough, lists, links, quotes, code, and tables. Single line breaks and blank-line paragraphs display in the timeline. Raw HTML is displayed as text. POST /api/v1/timeline or call MCP tool post_timeline with a JSON body containing caseId, date, title, and optional detail. Use JSON newline escapes in strings. Requires timeline:write. GET /api/v1/timeline?caseId=YOUR_CASE_ID or MCP tool get_timeline returns the stored Markdown text with timeline:read.
{
"caseId": "YOUR_CASE_ID",
"date": "2026-09-25",
"title": "**Documents filed**",
"detail": "Filed today.\nConfirmation received.\n\n- Motion\n- Supporting exhibits"
}