> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments and credentials

> Canonical named-environment isolation and scoped-key boundaries.

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.

## Recommended key separation

| Key                      | Environment binding   | Capabilities                                               |
| ------------------------ | --------------------- | ---------------------------------------------------------- |
| Runtime                  | One named environment | `runs:write`, `runs:read`, `engines:read`                  |
| Fixture runtime          | One sandbox           | Runtime grants plus `runs:test`                            |
| Webhook administration   | One named environment | `webhooks:manage`                                          |
| Restricted packet reader | One named environment | Runtime reads plus `runs:defensibility:read` when approved |

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](/reference/sandbox-fixtures) for copyable requests and
error codes.