⌘K

Health CompaniesGuide

Sandbox validation

The sequenced Sandbox validation flow and what each evidence step proves.

On this page

Sequence

  1. Health / authentication — the key authenticates in Sandbox.
  2. Program grant — an approved Sandbox Program is visible to the client.
  3. Program Catalog — an orderable item is readable.
  4. Serviceability — the item, region and collection method are serviceable. Failure stops all downstream writes.
  5. Synthetic subject — upsert with a synthetic SANDBOX- external reference.
  6. Idempotent order — create with an Idempotency-Key.
  7. Exact replay — the identical request returns the same order.
  8. Conflicting replay — the same key with a different body returns 409.
  9. Order retrieval and lifecycle/status.
  10. Optional canonical scenario — only where the runtime offers one.
  11. Released result — only if one was produced.
  12. Event evidence — bounded read of the event stream.
  13. Webhook delivery evidence — only if a matching canonical delivery exists.

Reading outcomes

  • Passed — the runtime returned the expected evidence, with HTTP status and request ID.
  • Failed — the runtime returned an unexpected response.
  • Skipped / gated — a prerequisite is absent (for example no released result or no delivery).

Limitation

Known discrepancy: the workspace validation sends a region body with the subject upsert, while the published contract for PUT /subjects/{externalSubjectId} defines no request body. Integrators should follow the published contract.

Warning

Skipped is not success, and a fully passed Sandbox run is not Production readiness. Validation never calls Production and uses synthetic references only.

Related resources