Complete your partner integration

After access approval, sign in with the invited, verified account and open Partner integrations. Accept the tenant administrator invitation. The console reports evidence from your tenant’s stored records and observed requests; it does not accept manually checked completion flags.

The eight-step readiness checklist covers a filing-capable integration. Use only the roles approved for your tenant. For an observer-only integration, follow the observer review path below.

1. Issue a test credential

Select an approved role and expiry. Store the credential in your backend secret manager while it is displayed. Use separate credentials for separate roles. An orchestrator coordinates a marketplace; it cannot accept terms or file an Answer for a party without that party’s authority. Rotate and revoke credentials in the same console.

2. Make a canonical request

Use your authorized test credential with GET /api/cases/{id} for an accessible case or prepare a filing through POST /api/filings. Follow the quickstart and claimant workflow. A successful authenticated canonical request supplies evidence; reading the public Rules without authentication cannot identify your tenant.

The usage panel counts authenticated calls by monitored route class, error responses and rate-limit responses beginning when monitoring is deployed. Revoked or unidentifiable credentials cannot contribute tenant-attributed counters. Honor Retry-After on 429. See rate limits for policy; these counters are not a quota reservation.

3. Register and verify a webhook

Enter your public HTTPS receiver URL. The Court refuses private, loopback and metadata addresses, rechecks DNS before transport, pins the allowed addresses and refuses redirects. For local development, use an HTTPS tunnel to the receiver example at examples/webhook-receiver/receiver.mjs.

Click Send signed verification. The ping uses the ordinary Ed25519 headers and case-event-v2 schema marker, with type: endpoint_verification, an event ID, a verification delivery ID, sequence: 1, occurrence time and a random hexadecimal challenge. Verification pings have their own sequence and do not advance the case-event cursor. They contain no case. Verify the signature, timestamp and exact request bytes before acknowledging. Return a 2xx response with x-pc-verification equal to the challenge. Only this response completes verification. See Keeping in sync for the signing contract and rotation.

The console displays verification attempts and up to 200 recent case deliveries. Payloads show the public sparse envelope; private evidence and internal notification text are excluded. Terminal deliveries can be replayed to the current active endpoint. A replay retains the event ID, creates a new delivery ID and remains subject to receiver deduplication. Rotate an existing endpoint through the documented webhook API.

4. Prepare a filing and obtain hosted acceptance

Prepare a canonical filing with the claimant’s identity and authority. Present its immutable review packet. The principal opens the hosted acceptance link, signs in and accepts the exact terms. The console detects the persisted hosted acceptance record. API preparation or confirmation cannot stand in for the principal’s acceptance.

5. Receive an Answer

Confirm the accepted filing and deliver the respondent invitation through the intended recipient’s authenticated channel. The respondent reviews the pinned terms and files its own Answer. The checklist detects a stored respondent Answer on a confirmed filing belonging to your tenant.

6. Read the served Award

Follow the case’s available actions and wait for service. Read GET /api/cases/{id}/award using an authorized credential, then verify its signed artifacts with your configured trust policy. An unsuccessful request or an unserved Award does not complete this step. Decision and execution explains finality, appeal stays and payment state.

Run the local canonical workflow

With repository dependencies installed and Node.js 22 or later, run npm run sandbox:partner -- --demo. It completes a synthetic filing, exact claimant acceptance, respondent Answer, multipart file evidence, signed callback failure/retry, mock Award and finality, and failed/retried simulated execution. The temporary JSON store and ephemeral keys are discarded on exit. No .env, database or provider credentials are inherited and outbound networking is blocked.

Use npm run sandbox:partner to keep a loopback HTTP server running until Ctrl-C. The bootstrap JSON provides its base URL, claimant/platform credentials, claimant and respondent sessions, valid filing body, callback capture URL and control token. Follow the complete curl walkthrough. Its local control endpoint supports clock advancement, failure injection, callback capture, mock case completion and simulated execution. Simulation receipts always have synthetic: true and paymentConfirmed: false, separate from the case’s canonical execution resource. Local controls do not exist on the hosted service, and this exercise does not complete the hosted tenant’s readiness checklist.

Explore the hosted stage samples

Click Create sandbox to provision six stage samples: prepared filing, awaiting Answer, exchange, served Award, appeal pending and final. Store the sandbox credential while it is displayed. Fetch the samples with:

curl --fail-with-body \
  --header "Authorization: Bearer $PEOPLES_COURT_SANDBOX_TOKEN" \
  "$PEOPLES_COURT_ORIGIN/api/sandbox/$PEOPLES_COURT_TENANT_ID/cases"

The response contains a test sandbox identity, generation, sandbox-case-v1 samples, and workflow: {command: "npm run sandbox:partner", demoCommand: "npm run sandbox:partner -- --demo", isolation: "temporary_local_process", synthetic: true}. The workflow points to the separate local exercise above. These are read-only integration examples, not filed proceedings or signed Awards. They use a separate sb_test_ credential namespace that the ordinary API cannot authenticate. There is no payment or provider path. The samples help you build stage displays; they do not complete real checklist steps.

Reset sandbox and revoke its old credential creates a fresh generation and credential. The previous credential immediately stops working. Reset history is retained without rewriting any legal record. Sandbox credentials expire after 30 days. Test tenants alone can provision this workspace.

Request live review

Once all eight checklist steps have evidence, click Request live review. The request captures the evidence references and timestamps for the administrator. Follow the review status and any requested changes in the console.

Readiness approval records the review decision. Live credential issuance still requires the bootstrap owner, the enabled live-provisioning deployment flag, the exact confirmation phrase, a live tenant and its approved role subset. A readiness request cannot turn a test tenant or sandbox into a live tenant.

Observer-only integrations

A read_only_observer credential can read cases made accessible to it; it cannot prepare filings, complete hosted acceptance, or submit an Answer. Complete credential setup, an authorized canonical read, and signed webhook verification. Test Award reads only on a served case that your tenant is authorized to access. The synthetic sandbox supports stage-display development without granting case access.

The console’s eight-step review remains a filing-workflow review, so an observer-only tenant does not need to acquire a filing role to satisfy it. For observer-only live access, submit the partner access application, select only the observer role and the read-only reporting workflow, and state “Observer-only live-access review” in the use-case description. Identify your existing test tenant and include your test request and webhook verification references. Use a distinct requested identifier for the proposed live integration. The form currently records test access only; describe the requested live review in that field for the owner to assess separately. The owner reviews this application through the existing access-review process; it does not create a console checklist completion or readiness approval. Any approved live tenant and credential remain subject to the same owner-only live-issuance gates.