File for the claimant
This guide uses partner role credentials and registered claimant authority to file a complaint whose respondent will answer on the Case Page. For account OAuth requests, use Get started. Act with claimant authority; a platform credential may coordinate the filing only under its registered authority grant. Keep bearer credentials on your server.
| Step | Actor and request | Expected result and next action | Interruption |
|---|---|---|---|
| Prepare | Authorized claimant or coordinator: POST /api/filings, with intakeMode: claimant_initiated, confirmationPolicy.mode: initiator_only, claimant authority, claimant acceptance identity, optional caseTrack (defaults to ai_standard), separate optional appealWaived election (defaults to false), typed requested relief, and an idempotency key. Omit respondent consent. | A draft ID, pinned Rules, fee, immutable digest, and exact confirmation requirements. Read GET /api/filings/{id} and obtain acceptance of the exact review packet as described below. | Missing or expired authority must be renewed before filing; never invent respondent consent. |
| Confirm | After the required packet acceptance, the authorized claimant confirms at POST /api/filings/{id}/confirmations, using the returned participant ID, digest, exact statement, actor/principal identity, and a new idempotency key. | The committed case ID and a show-once respondent link. Preserve the link through the intended respondent’s authenticated channel. | A changed digest requires review and a fresh confirmation. Retry identical input with the same key after an uncertain response. |
| Invite | Claimant or authorized coordinator: POST /api/cases/{id}/invitations when an invitation needs issuing or rotation. | A new invitation and a capability-free replay receipt. Continue with Invite someone to respond. | Rotation invalidates the old invitation; a replay cannot recover its secret. |
| Follow the Answer | GET /api/cases/{id} using a credential authorized for this case. | The stage, effective deadlines, and parties the case is waiting on. The respondent signs in, reviews the pinned terms, and files its own Answer. | Effective notice, fee, or account requirements can prevent advancement. |
| File | Claimant: multipart POST /api/cases/{id}/submissions, with x-pc-party: claimant, its own brief, attachments, required attestation, and an idempotency key. | The committed filing reference. Read the case view again for the next stage. | A closed stage or changed revision requires a refreshed view. An unavailable opponent filing remains sealed. |
| Check the record | Claimant: GET /api/cases/{id}/record-summary, then POST /api/cases/{id}/record-summary/confirmations with the exact returned digest and confirmation statement. | Confirmation of the claimant’s own source-bound record. | If the displayed record is inaccurate, propose a correction at POST /api/cases/{id}/record-summary/corrections before confirming — a partner caller needs restatement:respond on its case membership. Use a new idempotency key for a correction and reuse it only to retry that exact request. An applied correction records the party’s response. Refresh the case; confirm again only if a later preparation advertises confirm_record. Never alter a digest. |
| Follow the outcome | GET /api/cases/{id} and GET /api/cases/{id}/events. | Follow the decision and execution, including any appeal stay. | Service does not by itself establish payment or finality. |
Use the current case view’s availableActions, requirements, and revision for each mutation. The server rechecks authority and deadlines when writing. An idempotency key makes an identical retry recoverable; changing the body under that key is a conflict. Never log show-once party capabilities or invitations.
Claimant acceptance
Deliver the initial hostedAcceptanceUrl to the claimant through an authenticated channel. Supply the required claimantAcceptanceIdentity.email and optional .accountId when preparing. Acceptance requires the matching account ID or a signed-in account with the normalized, verified email (recorded verification or linked Google identity). A person may register first, then match. The external principal ID remains a delegation reference and never authorizes hosted access. The person reviews the claim, requested items, amount, Rules, AI disclosure, procedure and fees, then accepts the exact reviewPacket.termsDigest. The scoped link expires with the draft and is consumed once. It is not returned on preparation replay. GET /api/filings/{id} exposes the packet only to authorized claimant-side callers. Confirm at POST /api/filings/{id}/confirmations as the claimant or platform initiator. Without valid acceptance, acceptance_required returns the digest and, to an authorized claimant caller, a new hosted link. A changed packet requires fresh preparation and acceptance. The invitation is a one-time bearer capability. Until optional designated-email binding is configured, any eligible verified account that receives the link can claim the respondent slot; deliver it only through the intended respondent’s authenticated channel.
Other acceptance proofs
An existing claimant credential may explicitly register method: api_acceptance at /api/partner/consents when its registered filing authority binds that exact credential to the packet’s principal. Include filingDraftId, termsHash equal to the packet’s termsDigest, termsVersion: filing-review-packet-v1, and the packet’s scope, parties and transaction. Include procedureTerms exactly as returned in the review packet. Preserve the acceptance artifact reference and hash. Merely possessing a token or confirming the draft is not acceptance.
For wallet acceptance, designate claimantAcceptanceIdentity.walletAddress during preparation. The principal signs the exact reviewPacket.walletMessage; confirmation carries acceptance: { method: "wallet_signature", termsDigest, walletAddress, signature }. The signature binds the public case, exact packet, Rules and disclosure. Wallet control does not select a case track or waive an appeal.
A standing authority grant does not satisfy this filing’s exact-packet acceptance. Obtain case-specific hosted, authorized API or wallet acceptance of the returned terms, including the resolved track and any separate appeal election. Delegated filing authority remains separate from the principal’s case-specific consent.
Filing acceptance is distinct from respondent joinder and does not create respondent membership or consent.
Track and payment boundaries
Read the exact current procedure templates from GET /api/rules/current. ai_fast uses one bounded AI decision path, ai_standard uses three AI members, and ai_assisted_human assigns a human who may revise or reject the AI assistance and issues the Award. Every track retains a human appeal unless both parties expressly waive it; a human first-instance Award is appealed to a different human. For monetary claims, the human filing fee is USD 310 plus 5.67%, with no separate arbitrator charge. Rule 11.1 states final fees: AI-only 5.67% with a USD 1.67 minimum, AI-assisted human USD 310 plus 5.67%, and ruling-only USD 105 for AI-only or USD 520 for AI-assisted human. Use GET /api/fees/quotes?caseTrack=...¤cy=USD&minorUnits=... and the prepared packet’s fee; the server binds the price and procedure to the accepted packet. Payment and refund state in the canonical fee projection are status facts, not proof of a completed payment.
Choose AI-only or AI-assisted human. For AI-only, the Court resolves eligible monetary claims below USD 100 to ai_fast, and claims of USD 100 or more or nonmonetary relief to ai_standard, before acceptance. Review the resolved packet rather than inferring the procedure from your requested track. appealWaived defaults to false. Verified x402r, Virtuals ACP, AP2 and UCP referrals use this same default under the exact accepted Rules. Transaction or payment authority alone is never arbitration consent.
The election window runs from preparation through final case-opening confirmation, before the proceeding advances. Each party must accept the same different track and fee terms; any appeal waiver requires separate express acceptance. For protocol referrals, the bilateral referral authorization is the final confirmation. Historical cases retain their pinned terms. ACH is offered only in the native ordinary initial full-price filing checkout, not partner checkout, ACP checkout, appeals, evaluations, upgrades, promotions or credits.
Fast cases
In an AI-only fast case (Rule 4.12) each party may file at most 16,000 characters of normalized text, two text exhibits and ten extracted exhibit pages, text only. Each item counts against the party that filed it, across every filing, sealed filings included; the case summary, background facts and custom terms count against the claimant. One party never uses the other's allowance. Case opening, filing preparation, the Answer, every submission and the ACP and x402r referral intakes refuse material that would take the filing party past its allowance with 422 fast_track_record_limit and a detail naming the limit and the party. The Court never truncates a Record; each party files its best evidence. A fast case decides only the claimant's single monetary claim. An Answer that requests relief (money, a declaration or an order) is refused with 422 fast_track_counterclaim_not_available; the respondent files its own case. The Court retries a failed arbiter call until it decides and no longer offers a move to the standard procedure.
The case view’s deadlines are outstanding opportunities, not the complete filing schedule. A filed Answer has no upcoming Answer deadline; completed filing phases and expired post-Award windows remain in case history. The website, calendar offers and get_case_view use this same projection.