7. Environments and promotion

An environment is a separate place to build and run flows. You build in a lower environment, check the result, and promote the flow to the next one.

In the API an environment has a class: dev, qa, uat, staging or production. The default class is dev, so a new environment can never claim to be production by accident.

Work in one environment

Every request works in one environment:

Send the header X-Environment-Id: ENVIRONMENT_ID to choose it.
Send no header to use your workspace's default.

Check which one a request lands in:

curl https://api.inferrex.com/v1/workspace/environment \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "X-Environment-Id: ENVIRONMENT_ID"

Response shape: { id, name, class, isDefault, pinned }. pinned is true when the X-Environment-Id you sent was honoured. It is false when you sent none, or when the environment you chose no longer exists and the default was used instead. If you sent an id and pinned is false, stop: your writes would land in the default environment.

A flow belongs to the environment it was created in. GET /v1/pipelines lists the flows of the environment you are working in.

To do this	Call	MCP tool
List environments	`GET /v1/workspace/environments`	`workspace_environments_list`
Create one	`POST /v1/workspace/environments`	`workspace_environments_create`
Read the active one	`GET /v1/workspace/environment`	`workspace_get_active_environment`

In the app: Workspace settings, Environments.

Set a system up in each environment

The same system can point at a different address and sign in differently in each environment, for example a sandbox in Development and the live system in Production.

Bind the system to the environment: POST /v1/connection-environment-bindings with connection_id, environment_id and, if it differs, base_url.
Save that environment's credentials: POST /v1/connections/:id/credentials with environmentId.

Credentials are held per environment. Clearing a test environment's credentials cannot touch your live ones.

Set up the promotion path

POST /v1/workspace/promotion-edges/standard sets up the usual path between your environments: development, then QA, UAT, staging and production. GET /v1/workspace/promotion-edges lists the path.

Promote a flow

curl -X POST https://api.inferrex.com/v1/pipelines/PIPELINE_ID/promote \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"toEnvironmentId": "TARGET_ENVIRONMENT_ID"}'

Inferrex works out what would change in the target environment and how risky the change is. Changes to where data goes or how it syncs count for more than field edits. Then it checks your approval rules:

if they allow it, the change is applied straight away,
if not, it waits for someone to approve it.

Response shape: { id, status, riskLevel, changeCount, policyDecision, targetPipelineId, firstPromotion }.

A promotion is refused if any system the flow uses is not set up in the target environment, because the flow would fail on its first sync. Bind the system there first.

A promotion's status is pending_approval, applied, rejected or failed.

Who approves a promotion

With no approval policy of your own for promotions, a default ladder decides by the class of the target environment:

Target	Decision
Development and QA	Approved automatically.
UAT and Staging	Automatically when the change is low risk. Otherwise one approver.
Production	Never automatically. Two approvers.

Approvers are other members of your workspace who can edit flows, never the person who asked for the promotion. A policy of your own replaces the ladder. Read the ladder in force with GET /v1/pipeline-promotions/approval-ladder.

To do this	Call	MCP tool
List promotions, including those waiting	`GET /v1/pipeline-promotions`	`pipelines_list_pipeline_promotions`
Approve one	`POST /v1/pipeline-promotions/:promotionId/approve`	`pipelines_approve_pipeline_promotion`
Reject one (a reason is required)	`POST /v1/pipeline-promotions/:promotionId/reject`	`pipelines_reject_pipeline_promotion`

One rejection is enough. Nothing changes in the target environment, and the reason is kept so others can see why.

Next: InferrexAPI.