Get started

Open a test case draft

This guide exercises the smallest claimant-led v2 path: create a draft, inspect the server’s digest and participant state, then confirm it.

Before you start

Obtain a test credential from an authorized People’s Court operator, then store the show-once role-bound credential in a secret manager.

Keep credentials in environment variables or a secret manager. The examples contain placeholders only.

Step 1

Verify your credential

This harmless call returns the authenticated tenant, environment, role, capabilities, and any exporter or adapter resource binding. It does not create a case or consume a filing idempotency key.

Shell / cURL

export PEOPLES_COURT_BASE_URL="https://peoplescourt.ai"
export PEOPLES_COURT_TOKEN="pk_test_replace_me"

curl --fail-with-body   --url "$PEOPLES_COURT_BASE_URL/api/v2/integration"   --header "Authorization: Bearer $PEOPLES_COURT_TOKEN" | jq .

Step 2

Register the case authorizations

A claimant-agent credential records its authority assertion and claimant consent assertion. For this claimant-initiated example, the respondent does not pre-consent through the API; they consent later through the hosted login link. These calls authenticate the role-bound partner credential, but do not retrieve the referenced artifacts or verify an underlying principal signature or email delivery. A platform-orchestrator credential cannot make a party’s assertion.

Use the returned authorityGrantId and claimant consentArtifactId in the draft request below. Other intake modes still require a distinct respondent consent artifact. The example placeholders are not provisioned records.

Step 3

Create the draft

This example selects the claimant-led workflow. The response contains the canonical draft, digest, participant identifiers, pinned Rules and procedure, fee data, and outstanding confirmations.

Shell / cURL

export PEOPLES_COURT_BASE_URL="https://peoplescourt.ai"
export PEOPLES_COURT_TOKEN="pk_test_replace_me"

draft_response="$(curl --request POST \
  --url "$PEOPLES_COURT_BASE_URL/api/v2/case-drafts" \
  --header "Authorization: Bearer $PEOPLES_COURT_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: draft-test-0001" \
  --data '{
    "externalCaseId": "marketplace_case_123",
    "transactionId": "transaction_test_123",
    "policyVersion": "2026-08-test",
    "authorityGrantId": "grant_test_123",
    "consentArtifactIds": {
      "claimant": "consent_claimant_test_123"
    },
    "claimAmount": { "currency": "USD", "minorUnits": "12500" },
    "parties": {
      "claimant": { "externalId": "buyer_test_123", "name": "Test Buyer" },
      "respondent": { "externalId": "seller_test_123", "name": "Test Seller" }
    },
    "summary": "Test-environment delivery dispute",
    "claim": {
      "statement": "The test delivery did not match the agreed specification.",
      "requestedOutcome": "refund"
    },
    "intakeMode": "claimant_initiated",
    "confirmationPolicy": { "mode": "initiator_only" }
  }')"

printf '%s\n' "$draft_response" | jq .

Keep the response’s real draftId, claimant participantId, and draftDigest. Never calculate or replace the server digest locally.

Step 4

Review, then confirm

Fetch the draft before confirmation and show the exact case terms to the authorizing principal. The command selects the claimant participant once, then copies its participant, principal, and agent IDs together with the digest and exact server-generated confirmationStatement; do not hardcode identity or rewrite the statement.

Shell / cURL

draft_id="$(printf '%s' "$draft_response" | jq -r '.data.draftId')"

reviewed_draft="$(curl --request GET \
  --url "$PEOPLES_COURT_BASE_URL/api/v2/case-drafts/$draft_id" \
  --header "Authorization: Bearer $PEOPLES_COURT_TOKEN")"

claimant_participant="$(printf '%s' "$reviewed_draft" | jq -c '.data.participants[] | select(.side == "claimant")')"
participant_id="$(printf '%s' "$claimant_participant" | jq -r '.participantId')"
principal_id="$(printf '%s' "$claimant_participant" | jq -r '.principalId')"
actor_id="$(printf '%s' "$claimant_participant" | jq -r '.agentId')"
draft_digest="$(printf '%s' "$reviewed_draft" | jq -r '.data.draftDigest')"
confirmation_statement="$(printf '%s' "$reviewed_draft" | jq -r '.data.confirmations[] | select(.side == "claimant") | .confirmationStatement')"

jq -n \
  --arg participantId "$participant_id" \
  --arg draftDigest "$draft_digest" \
  --arg confirmationStatement "$confirmation_statement" \
  --arg actorId "$actor_id" \
  --arg principalId "$principal_id" \
  '{
    participantId: $participantId,
    draftDigest: $draftDigest,
    confirmationStatement: $confirmationStatement,
    actorId: $actorId,
    principalId: $principalId,
    confirmationMethod: "protocol_act",
    confirmationReference: "partner_confirmation_test_123"
  }' | curl --request POST \
  --url "$PEOPLES_COURT_BASE_URL/api/v2/case-drafts/$draft_id/confirmations" \
  --header "Authorization: Bearer $PEOPLES_COURT_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: confirm-test-0001" \
  --data-binary @-

A 201 response means the required confirmations opened the case. A 202 response means another participant confirmation is still outstanding.

Step 5

Continue by server state

Fetch the returned case resource and follow its current phase. The successful confirmation returns a show-once respondentLoginPath. Send that link to the intended respondent through your authenticated channel; they sign in, review the pinned terms, and accept while filing their Answer. Use respondent handoff only to rotate the link. Then submit only in the server-selected stage, confirm each side’s record, and poll decision status or consume signed callbacks.

Issue respondent handoff File the Answer Submit a party record Read decision status

Machine resources

Raw contracts and agent-oriented files are secondary to the human documentation.

View raw OpenAPI Agent instructions (Markdown) llms.txt