8 days ago
We are asking only about generic current supported behavior; official documentation URLs are welcome. Please do not inspect any private target. We will not provide or request tokens, project IDs, environment IDs, service IDs, repository names, trace IDs, account data, customer data, or private target details. Please do not create a service or perform or request a live mutation.
Can a Railway project token scoped to one project environment execute serviceInstanceAutoDeployUpdate for a service in that environment when the input supplies projectId, environmentId, serviceId and enabled?
Can the same project token execute serviceInstanceUpdate for that service and environment?
If either mutation is not permitted to a project token, what is the least-privilege Railway token role and scope that permits it?
We need only the generic current supported behavior and any official documentation URLs; please do not inspect a private target or request/include tokens, project/environment/service IDs, repository names, trace IDs, account/customer data, or private target details. Please do not create a service or perform or request a live mutation.
1 Replies
8 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 8 days ago
2 days ago
Hi, to answer you questions:
- serviceInstanceAutoDeployUpdate: a project token is not sufficient.
- serviceInstanceUpdate: a project token is not sufficient.
- The least-privilege broader token is a workspace token, assuming the workspace contains the target project. An account token would also work but is broader.
Railway's API docs define project tokens as environment-scoped, while workspace tokens have access across the workspace. From experience service-instance API operations fail with project tokens and work with broader-scoped tokens.