I think the slightly confusing part here is that the service ID itself isn't different between production and staging.

The serviceId identifies the service, while the environmentId selects which environment's instance/config you're changing.

So for a variable that should only exist/update on that service in staging, I'd use something like:

mutation variableUpsert($input: VariableUpsertInput!) {
  variableUpsert(input: $input)
}

with:

{
  "input": {
    "projectId": "PROJECT_ID",
    "environmentId": "STAGING_ENVIRONMENT_ID",
    "serviceId": "SERVICE_ID",
    "name": "MY_VARIABLE",
    "value": "new-value",
    "skipDeploys": true
  }
}

A couple important details:

• Keep serviceId in the input. If you leave it out, Railway treats it as a shared variable for that environment.
• Make sure environmentId is the actual staging environment ID. That's what prevents the production value from being touched.
• skipDeploys: true updates the variable without immediately deploying the service. Remove it/set it to false if you want the variable change to trigger a deployment.

For multiple variables I'd use variableCollectionUpsert instead:

mutation variableCollectionUpsert($input: VariableCollectionUpsertInput!) {
  variableCollectionUpsert(input: $input)
}

{
  "input": {
    "projectId": "PROJECT_ID",
    "environmentId": "STAGING_ENVIRONMENT_ID",
    "serviceId": "SERVICE_ID",
    "variables": {
      "VAR_ONE": "value",
      "VAR_TWO": "value"
    },
    "skipDeploys": true
  }
}

I would also avoid replace: true unless you actually want Railway to remove every other variable that isn't included in the payload.

You can verify the result without deploying by querying variables again with the same project/environment/service IDs.

So if the concern is that the same serviceId exists in both prod and staging, that's expected — environmentId is the part that scopes the update to staging.

We send OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS as direct variable-node JSON null values through environmentStageChanges(merge:true), but environmentStagedChanges.patch(decryptVariables:false) returns masked {value:string} objects.

Is setting the variable node itself to JSON null the supported deletion representation for this exact environmentStageChanges(merge:true) operation? If so, which supported read or metadata field can verify that these two variables are recorded as actual DELETE operations in the existing pending changes, without revealing values or committing/deploying anything?

If account-specific investigation is necessary, please identify an authorized private support channel available to a Trial account. We will not post private identifiers or credentials here.