Environments can also be managed in the KeyStone Dashboard under Settings > Environments - no code required.
Environments provide data isolation within a platform (e.g., development, staging, production). Each environment has its own settlements, webhooks, IP allowlists, and M2M credentials.
create
Any other key is rejected with 422. Webhook delivery is configured per endpoint
under webhooks, not on the environment.
auth0ClientId must be an M2M application your Keystone operator has already
created and authorized against the Keystone API. Keystone verifies this before
saving the environment: a client id that is not authorized for the Keystone API
(including a client id that does not exist, or one belonging to a different API)
is rejected with 422 UNRECOGNIZED_CLIENT, and an empty value is rejected as a
validation error. The same check runs on secret rotation.
list / get
EnvironmentRead
update
These two fields are the whole update surface; any other key is rejected with
422 rather than silently ignored. isActive is changed through deactivate
below, and rateLimitRpm is set by your Keystone operator.
deactivate
Deactivate an environment. Preserves all data but blocks M2M authentication using this environment’s credentials once the deactivation commits.
Deactivation closes the environment to new settlements: resting instructions no
longer match, and no repo closing settlement is derived while it is inactive.
It does not stop settlements already in flight - they keep advancing to
completion, and their webhooks keep delivering.
This is the only way to deactivate an environment, and it is one-way. Reactivation
is performed by a Keystone operator on request: the environment’s own credentials
stop authenticating once the deactivation commits, so no call you can make would
reach it.