Launch readiness is mostly operational discipline: correct credential shape, traceable writes, verified webhook delivery, a real golden-path rehearsal, and a rollback packet that support can act on without guesswork.
ae140b8f3b926d06Keep your launch packet on the same contract hash as the deployment you are validating.
| Gate | Verify with | What you must prove | Evidence to keep |
|---|---|---|---|
| Environment and contract pin | GET /v1/partner-organizations/{partnerOrgId} | Your integration points at the intended DutyClaims environment and the same contract hash that produced your downloaded OpenAPI, starter files, and examples. | Record the target host, contract hash, and the exact generated artifacts the team used during the rehearsal. |
| Credential and header discipline | GET /v1/partner-organizations/{partnerOrgId}/capabilities | Production traffic uses the credential shape the current route family actually publishes. Do not treat sandbox OAuth as proof of a production flow. | Keep one successful authenticated read plus the rotation owner and secret-storage location for the live credential. |
| Traceability and idempotency | POST /v1/claims | Write paths send and persist `Idempotency-Key`, `X-Correlation-Id`, and the returned request identifiers so retries and support escalations stay replay-safe. | Capture one write log showing the outbound idempotency key plus the response `requestId` and `correlationId`. |
| Webhook readiness | POST /v1/sandbox/webhooks/test | The receiving service stores the signing secret, verifies the HMAC against the raw body, and routes only after verification succeeds. | Keep one successful endpoint registration plus one successful synthetic sandbox delivery and the receiving-service log entry that validated it. |
| Golden-path rehearsal | GET /v1/claims/{claimId}/status | You have run the actual flow you intend to ship, not just isolated curl calls. For most teams that means client, authority, claim creation, status read, and webhook observation. | Record the partner client ID, claim ID, and any webhook delivery identifiers from the rehearsal run. |
| Support and rollback packet | GET /v1/webhook-deliveries | On-call and partner-support teams know which metadata to include when traffic misbehaves and how to fall back during migration windows. | Prepare the escalation template with route, timestamp, request ID, correlation ID, partner org, claim/job ID, and the current cutover owner. |
requestId from every non-2xx response and every rehearsal write.correlationId or your outbound X-Correlation-Id.| Step | Route | Success signal |
|---|---|---|
| 1 | GET /v1/partner-organizations/{partnerOrgId} | Partner org and environment match the tenant you intend to launch. |
| 2 | POST /v1/webhooks/endpoints | Endpoint is registered and the signing secret is stored outside source control. |
| 3 | POST /v1/sandbox/webhooks/test | Receiver validates the signature and records the event. |
| 4 | POST /v1/clients | The canonical client identifier is created or linked and persisted by your app. |
| 5 | GET /v1/clients/{clientId}/authority | Authority state is truthful before any downstream claim or notification work starts. |
| 6 | POST /v1/claims | A write path succeeds with replay-safe headers and returns stable identifiers. |
| 7 | GET /v1/claims/{claimId}/status | Status reads and webhook deliveries agree on the lifecycle change you triggered. |