Matters Overview

Matters are the workspace primitive for legal work on Case.dev. A matter owns the operating context: metadata, its primary vault, work items, parties, audit logs, and sharing.

Open API All Services

CreatePOST /matters/v1

TrackPOST /matters/v1//work-items

DecidePOST /matters/v1//work-items//decision

What a matter owns

Primary vault linkage
Work items and decision history
Reusable parties and matter-specific roles
Optional playbook (matter type) for agent instructions
Audit logs, exports, events, and shares

Core resources

Resource	Endpoint family	Purpose
Matter	`/matters/v1`	Create, update, and inspect legal workspaces
Matter types	`/matters/v1/types`	Optional playbooks with agent instructions
Agent types	`/matters/v1/agent-types`	Reusable agent role definitions
Parties	`/matters/v1/parties`	Reusable people and organizations
Matter parties	`/matters/v1/{id}/parties`	Attach parties to a matter with roles
Work items	`/matters/v1/{id}/work-items`	Create and manage legal tasks
Decisions	`/matters/v1/{id}/work-items/{workItemId}/decision`	Approve or block work
Logs	`/matters/v1/{id}/log`	Operational history and exports
Shares	`/matters/v1/{id}/shares`	Cross-org matter access

How it works

The matters API is a task board and system of record for legal work.

Create a work item to describe and track a unit of work.
Perform intensive agent work in Linc and attach the results to your application workflow.
Update the work item as its state changes.
Record a decision to approve or block the work.

Work items can keep application-specific dependencies and result references in metadata.

Quickstart

Shell

# Create a matter
curl https://api.case.dev/matters/v1 \
  -H "Authorization: Bearer $CASEDEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Doe v. Example Corp.",
    "practice_area": "litigation"
  }'

Shell

# Create a work item
curl https://api.case.dev/matters/v1/$MATTER_ID/work-items \
  -H "Authorization: Bearer $CASEDEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Review demand letter",
    "type": "review",
    "instructions": "Check all citations and verify damages calculations against the medical records."
  }'

Shell

# Block a work item with a reason
curl https://api.case.dev/matters/v1/$MATTER_ID/work-items/$WORK_ITEM_ID/decision \
  -H "Authorization: Bearer $CASEDEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "decision": "block",
    "reason": "Citation on page 3 was overturned in 2024."
  }'

Listing matters

GET /matters/v1 supports cursor pagination, newest update first. Pagination is opt-in: pass limit to receive a bounded page. A request with neither limit nor cursor still returns every matter.

Parameter	Type	Description
`limit`	integer	Matters per page, `1`–`200`. Omit to receive every matter.
`cursor`	string	Opaque continuation cursor from the previous page’s `next_cursor`.

Every response carries a pagination object. Unpaginated requests report limit: null and has_more: false:

{
  "data": [{ "id": "matter_...", "title": "Doe v. Example Corp." }],
  "pagination": {
    "limit": 50,
    "has_more": true,
    "next_cursor": "eyJ1IjoiMjAyNi0wMS0wMVQwMDowMDowMC4wMDBaIi..."
  }
}

The unpaginated default is going away. A request without limit currently returns every matter. A future release will bound it to a default page size. Start passing limit and following next_cursor now and that change will be a no-op for you.

To read the whole list, keep requesting while has_more is true, passing the previous next_cursor as ?cursor=:

Shell

CURSOR=""
while :; do
  PAGE=$(curl -s "https://api.case.dev/matters/v1?limit=100&cursor=$CURSOR" \
    -H "Authorization: Bearer $CASEDEV_API_KEY")

  echo "$PAGE" | jq -r '.data[].id'

  [ "$(echo "$PAGE" | jq -r '.pagination.has_more')" = "true" ] || break
  CURSOR=$(echo "$PAGE" | jq -r '.pagination.next_cursor')
done

Cursor rules

Cursors are opaque: do not parse, construct, or persist them. They encode the sort position of the last row on a page (updated_at and id, so matters sharing a timestamp are never skipped or repeated) together with the filters they were issued under.

Replay a cursor with exactly the same status, matter_type, practice_area, and query values that produced it. Changing a filter mid-pagination returns 400 INVALID_CURSOR rather than silently blending two result sets.
Cursors are scoped to the organization and API key that minted them. Another tenant’s cursor returns 400 INVALID_CURSOR.
A limit outside 1–200, or a non-integer, returns 400 INVALID_LIMIT. Out-of-range values are rejected, not clamped.
Passing a cursor without a limit pages at the default size of 50.

Matters are ordered by updated_at descending. Because that column changes as matters are edited, a matter updated during a traversal can move between pages. Pin status or a narrow query when you need a more stable window. The full schema and every tagged operation live in the API Reference.

Get Started

Platform

Resources

What a matter owns

Core resources

How it works

Quickstart

Listing matters

Cursor rules

​What a matter owns

​Core resources

​How it works

​Quickstart

​Listing matters

​Cursor rules

What a matter owns

Core resources

How it works

Quickstart

Listing matters

Cursor rules