GETpartial

List confirmed case participants and authority

List confirmed case participants and authority Canonical resource. Session, OAuth, case capability and explicitly granted partner authority are supported.

/api/cases/{id}/participantsgetCaseParticipantsCanonical

Authentication and authority

Use one listed account-session, scoped OAuth, or partner credential alternative. Account tokens retain the approving account’s authority. Cookie-authenticated writes require same-origin authorization. Alternatives are OR; schemes in one alternative are AND.

platformOrchestratorBearer

Credential bound to the platform_orchestrator role.

claimantAgentBearer

Credential bound to the claimant_agent role. Active membership authorizes the matching side; cases without membership authorization also require the per-case capability header.

respondentAgentBearer

Credential bound to the respondent_agent role. Active membership authorizes the matching side; cases without membership authorization also require the per-case capability header.

CanonicalSession

AccountOAuth

Account tokens authorize only their approving account and case scope. S256 PKCE is mandatory on the code flow. Explicit reacceptance is required after Rules/disclosure changes.

Parameters

NameLocationRequirementSchema
idpathRequired{"type":"string"}
x-arb-party-token

Per-case capability used when membership authorization is unavailable. Optional with active membership for the matching side.

headerOptional{"type":"string"}

Responses

200

Confirmed participants and their explicitly granted case operations.

application/json

{
  "type": "object",
  "properties": {
    "data": {
      "type": "object",
      "properties": {
        "schemaVersion": {
          "const": "case-participants-v2"
        },
        "caseId": {
          "type": "string"
        },
        "participants": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "participantId": {
                "type": "string"
              },
              "side": {
                "type": "string",
                "enum": [
                  "claimant",
                  "respondent"
                ]
              },
              "name": {
                "type": "string"
              },
              "status": {
                "type": "string"
              },
              "principalId": {
                "type": "string"
              },
              "partnerId": {
                "type": "string"
              },
              "agentId": {
                "type": "string"
              },
              "allowedOperations": {
                "type": "array",
                "items": {
                  "$ref": "#/components/schemas/CaseMembershipOperationV2",
                  "type": "string",
                  "enum": [
                    "case:read",
                    "submission:create",
                    "restatement:respond",
                    "record:confirm",
                    "case:terminate",
                    "award:read",
                    "message:create",
                    "evidence:challenge"
                  ],
                  "description": "Explicit per-case membership authority. Reads use case:read, procedural-message POST uses message:create, and authenticity-challenge POST uses evidence:challenge. A party token does not override a restricted active membership. Missing grants refuse with case_operation_forbidden. Existing memberships are not automatically expanded; the provisioning owner must grant new write operations explicitly."
                }
              }
            }
          }
        }
      }
    },
    "requestId": {
      "type": "string"
    }
  }
}
default

RFC 9457 style problem response.

application/problem+json

{
  "$ref": "#/components/schemas/Problem",
  "type": "object",
  "required": [
    "type",
    "title",
    "status",
    "code",
    "detail",
    "requestId"
  ],
  "properties": {
    "type": {
      "type": "string",
      "format": "uri"
    },
    "title": {
      "type": "string"
    },
    "status": {
      "type": "integer"
    },
    "code": {
      "type": "string"
    },
    "detail": {
      "type": "string"
    },
    "requestId": {
      "type": "string"
    }
  }
}

Example response

Successful response

{}

Errors

Read the response status and stable error code. See errors and rate limits for recovery. Refresh the resource before resolving a state or digest conflict.

Idempotency and retries

  • For throttling, honor Retry-After when present. Back off on retryable server failures.