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 claimant workflow with your registered authority grant and claimant acceptance identity. Get started is a separate account OAuth walkthrough; its account token cannot stand in for a partner role credential. A successful authenticated canonical request supplies evidence; reading the public Rules without authentication cannot identify your tenant.

The usage panel shows your integration’s authenticated request counts, errors and rate-limit responses. 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, expose your receiver through an HTTPS tunnel.

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.

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, and sandbox-case-v1 samples. 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 credentials are then issued separately by People’s Court, for 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. People’s Court issues live credentials separately after eligibility approval.