Skip to main content
A canonical environment is the isolation boundary for partner resources. Every environment has a stable UUID, a human-readable slug, and kind live or sandbox. Scoped credentials bind to the canonical environment UUID at issuance. Runs, polling reads, defensibility packets, webhook endpoints, delivery history, delivery detail, and resend authorization all enforce that binding. A resource in another named environment is not selected merely because both environments share the legacy test compatibility label. The environment field in existing run and webhook response objects remains the compatibility label test or live. It is not the authorization boundary. Use the credential’s named-environment binding for isolation and operational routing. Do not reuse a live key in a sandbox or a sandbox key in live. Create a distinct principal for each environment and integration responsibility.

​
Fixture sandbox contract

A deterministic fixture request requires all of the following:
  • canonical environment kind sandbox
  • runs:test in addition to runs:write
  • an explicit exact engine_version
  • a version present in the published supported-version registry
  • test_scenario equal to completed, degraded, or failed
The fixture runs through normal admission, storage, queue, terminal, polling, webhook, usage-cap, and retention paths with zero provider egress. Live environments reject test_scenario before creating a run. See Sandbox fixtures for copyable requests and error codes.