# Partner onboarding package and receipt

The one-hour integration clock starts only after Chia has delivered a complete, environment-bound onboarding package and both environments resolve. This is technical integration time; it does not include infrastructure deployment, contract/legal approval, catalog certification, or live-pilot activation.

Successful delivery binds the public artifacts to exact deployed origins and credential roles. Production use additionally requires the signed activation record naming the approved catalog, commercial terms, support owner, and release digest.

## Required package

The named Chia release-delivery contact supplies all of these files together:

- `release-manifest.json`;
- `release-manifest.sha256`;
- `release-manifest.sigstore.json`;
- the manifest-named `chia-partner-integration-2.1.0.tgz` and its `.sha256` file;
- the manifest-named `chiahealth-partner-2.1.0.tgz` and its `.sha256` file.

The integration archive is self-contained: it preserves the documented layout for `partner-docs/`, `api/partner/`, the offline compatibility checker, complete SDK source project, reference backend/mobile examples, and `sdk/<manifest-named SDK tarball>`. The partner does not need access to Chia's source repository or a package registry.

From the delivery directory, authenticate the manifest to the exact Chia release workflow before trusting any filename or digest:

```bash
set -euo pipefail
cosign verify-blob \
  --bundle release-manifest.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity https://github.com/200labs/biotwin/.github/workflows/build-partner-release.yaml@refs/heads/main \
  release-manifest.json
python3 - release-manifest.json release-manifest.sha256 <<'PY'
import hashlib, hmac, pathlib, sys

artifact = pathlib.Path(sys.argv[1])
companion = pathlib.Path(sys.argv[2])
actual = hashlib.sha256(artifact.read_bytes()).hexdigest()
expected_line = f"{actual}  {artifact.name}\n"
if not hmac.compare_digest(companion.read_text(encoding="ascii"), expected_line):
    raise SystemExit("release manifest checksum mismatch")
PY

integration_archive="$(jq -er '.integration_bundle.archive | select(test("^chia-partner-integration-[0-9]+\\.[0-9]+\\.[0-9]+\\.tgz$"))' release-manifest.json)"
integration_sha="$(jq -er '.integration_bundle.sha256 | select(test("^[0-9a-f]{64}$"))' release-manifest.json)"
sdk_archive="$(jq -er '.sdk.tarball | select(test("^chiahealth-partner-[0-9]+\\.[0-9]+\\.[0-9]+\\.tgz$"))' release-manifest.json)"
sdk_sha="$(jq -er '.sdk.sha256 | select(test("^[0-9a-f]{64}$"))' release-manifest.json)"
python3 - \
  "$integration_archive" "$integration_sha" "$integration_archive.sha256" \
  "$sdk_archive" "$sdk_sha" "$sdk_archive.sha256" <<'PY'
import hashlib, hmac, pathlib, sys

for offset in (1, 4):
    artifact = pathlib.Path(sys.argv[offset])
    expected = sys.argv[offset + 1]
    companion = pathlib.Path(sys.argv[offset + 2])
    actual = hashlib.sha256(artifact.read_bytes()).hexdigest()
    if not hmac.compare_digest(actual, expected):
        raise SystemExit(f"archive checksum mismatch: {artifact.name}")
    expected_line = f"{expected}  {artifact.name}\n"
    if not hmac.compare_digest(companion.read_text(encoding="ascii"), expected_line):
        raise SystemExit(f"companion checksum mismatch: {companion.name}")
PY
```

Reject the package if keyless verification, exact issuer/identity matching, manifest checksum, either signed-manifest archive hash, or either companion checksum comparison fails. A checksum delivered beside an archive is not a trust root by itself.

The package also includes this exact inventory for each environment:

| Field | Sandbox | Production |
|---|---|---|
| API origin | Exact working HTTPS origin from signed onboarding | Separate exact working HTTPS origin from signed onboarding |
| Asset origin | Exact working HTTPS origin from signed onboarding | Separate exact production asset origin |
| Care origin | Exact isolated working origin from signed onboarding | Exact Chia production origin |
| Runtime key | One `chia_test_…` secret | One `chia_live_…` secret |
| Finance key | Separate `chia_test_finance_…` secret | Separate `chia_live_finance_…` secret |
| Webhook signing secret | One `whsec_test_…` secret | Separate `whsec_live_…` secret |
| Registered webhook | Exact partner HTTPS URL and endpoint version | Separate exact partner HTTPS URL and endpoint version |
| Generic return | Exact pre-registered partner URL, if approved | Separate exact pre-registered partner URL, if approved |
| Integration support | Named contact, authenticated channel, hours, and response target in the signed receipt/agreement | Separately confirmed production escalation path |
| Security incident contact | Named contractual security channel and acknowledgement target | Same, revalidated before activation |

Raw credentials are placed directly into the named partner secret-manager destinations through the mutually approved secret-delivery channel. They are never placed in the release manifest, email, chat, tickets, CI artifacts, mobile configuration, logs, or source control. Each credential is bound to exactly one partner tenant, one environment, and one narrow role; neither credentials nor signing secrets may be reused across tenants or environments. The non-secret receipt records tenant, environment, credential role/public prefix, release commit/digest, integration-bundle and SDK SHA-256 values, endpoint version and host, delivery time, recipient identity, acknowledgement evidence hash, and the current named integration/security escalation channels. No hard-coded mailbox in these docs substitutes for that receipt.

The package is incomplete—and the clock does not start—if any signed-release artifact above is missing, any verification fails, a supplied origin is unresolved, any of the six environment/role credentials is missing, runtime/finance/receiver roles are not separately scoped, either webhook endpoint is not DNS/TLS validated, the extracted integration archive lacks a documented file, or a named engineering contact is unavailable.

## Connectivity receipt

Before starting implementation, record these non-secret checks for each environment:

| Check | Evidence |
|---|---|
| sandbox runtime authentication | catalog HTTP status, `Chia-Version`, `Chia-Request-Id`; never body/credential |
| care-origin configuration | exact approved origin hash and TLS/DNS ownership result; never a handoff URL |
| sandbox finance authentication | summary-list HTTP status, `Chia-Version`, `Chia-Request-Id`; never body |
| production runtime authentication before activation | expected fail-closed catalog/handoff status and stable `production_catalog_not_approved` code, plus version/request ID and all three accepted synthetic webhook tests; never body/credential/URL |
| production commerce after activation | live catalog status/version/request ID plus accepted identity-free handoff; never body/credential/URL |
| production finance authentication | status/version/request ID plus release-count and cursor-shape only; never body/credential |
| webhook endpoint | exact registered URL hash, public DNS/TLS result, endpoint version, active ownership-proof receipt hash/status; never challenge/body |
| signed delivery | one receiver-owned receipt per synthetic event type, with environment/test flags |
| artifact identity | release commit/digest plus manifest, bundle, and SDK SHA-256 |

The workflow's onboarding/change-record SHA-256 proves only which reviewed
operator record authorized the attempt. It never proves endpoint ownership.
Provisioning itself sends a fresh random challenge to the exact URL through
Chia's controlled CONNECT egress and records the resulting non-secret receipt;
failure happens before any credential is staged or endpoint is enabled.

Every production synthetic test must be `livemode:true` and `test:true`. The live catalog and handoff use `livemode:true` without exposing a user identity or individual outcome to the partner.

## Acceptance sequence

1. Run the exact keyless and hash-verification block above. Extract the exact integration archive, enter its single top-level directory, run `python3 scripts/partner_contracts/verify_integration_bundle.py .`, then install `sdk/<manifest-named SDK tarball>`.
2. Store each credential only in its designated backend/worker secret scope. In both environments, confirm the catalog process rejects webhook/finance credentials, the webhook receiver rejects runtime/finance credentials, and the finance worker rejects runtime/webhook credentials.
3. From a runtime-only job, run `bash partner-docs/curl-quickstart.sh runtime`; it fetches and discards the catalog as a connectivity check. Use the reference `test-webhooks` process later in the checklist for all three durable synthetic requests. From a separate finance-only job, run `bash partner-docs/curl-quickstart.sh finance`; it fetches and discards one settlement page as a connectivity check. Each curl mode rejects credentials belonging to the other role and prints only a fixed status label.
4. Deploy the receiver, then have Chia validate the exact sandbox URL with the ownership challenge. Confirm a `2xx` and the non-secret ownership-proof receipt before enabling signed delivery. The challenge request must not create a dedupe receipt, job, or business side effect.
5. Confirm all three event IDs reached the correct environment receiver and took the `test: true` no-side-effect path. An API `202` alone is not delivery proof.
6. Exercise asset integrity, local `hidden` / `neutral_only` / `share_or_neutral` decisions, exact JIT copy, and OS-browser handoff in sandbox.
7. Validate the distinct production receiver with a separate ownership
   challenge. Using separate production runtime and finance jobs, verify
   authentication, the expected fail-closed catalog/handoff response, all
   three synthetic webhook shapes, and strict traversal of any
   Finance-released production revisions. This certification does not require
   or imply commerce activation.
8. After the agreement and every legal/product/security gate is complete, Chia
   and the partner sign the non-secret activation receipt. Re-run production
   catalog and identity-free handoff checks, then complete one authorized
   end-to-end production purchase: the OS browser shows the credential-bound
   `<Partner> × Chia` co-brand, Chia collects payment, and no
   patient/order/shipment callback or row reaches the partner.

External receiver-ack certification is a launch blocker in each environment:
Chia's ownership-proof receipt confirms control of the URL, but only the partner's
receiver-owned acknowledgements for all three signed synthetic events confirm
that its deployed signature, dedupe, queue, and no-side-effect paths work.

After acceptance, complete the [integration definition of done](https://partners.chia.health/docs/go-live/#integration-definition-of-done) and preserve its non-sensitive certification evidence with this receipt.

Webhook URL changes and credential rotations are control-plane operations. Send the exact environment, new HTTPS endpoint, ownership/TLS evidence, requested effective time, and named approver through the contractual engineering channel. Do not send a signing secret or API key in that request.