The live schema is the authoritative contract, so deploymentRollback returns a Boolean, and a true result tells you the rollback was accepted rather than handing back the new deployment. The example that selects id and status on it doesn't match the current schema.

We haven't verified any response field or query that ties a specific deploymentRollback call to the deployment it creates, and we can't confirm a correlation guarantee for two clients rolling back to the same target at nearly the same time. Listing recent deployments for the service with the deployments query and its createdAt field shows the new deployment after the fact. That works as an observation, but we can't confirm it tells concurrent rollbacks apart.

Thanks for clarifying what true means. Could a Railway engineer review two questions about concurrent rollbacks?

1. If two clients call deploymentRollback for the same service, environment and target, is there a supported receipt, request ID or audit record that maps each accepted call to the specific deployment ID it created? If so, how can the caller retrieve that mapping?

2. If that mapping is unavailable, does Railway offer a server-side lock or conditional rollback that prevents a second rollback while the first is in progress, including one initiated from the dashboard or another API session? How can we verify that protection, and is it available on Hobby?

If neither guarantee is available, explicit confirmation would help us choose the right operating procedure.

On the first question, the deploymentRollback response is just the Boolean, so the call returns no receipt, request ID or deployment ID. We also don't provide internal request or trace IDs or per-request correlation beyond what your workspace audit logs show. We can't confirm any supported mapping from an accepted rollback call to the deployment it created, so you shouldn't rely on one.

On the second question, we can't confirm a server-side lock, idempotency key or conditional rollback that stops a second rollback while the first is running, whether it comes from the API, another session or the dashboard. That applies on Hobby or any other plan. For your operating procedure, it's safest to assume neither guarantee exists and to serialize rollbacks on your side.