I'd split this into three requests before changing the token's permissions.

Railway explicitly documents projectToken for project tokens. Send a POST to https://backboard.railway.com/graphql/v2 with Content-Type: application/json and your existing Project-Access-Token header, using only this body:

{"query":"query { projectToken { projectId environmentId } }"}

Don't include an Authorization: Bearer header for this test. A project token is scoped to one environment, not every environment in the project.

If that succeeds, check the returned IDs privately, then try service and serviceInstance separately with minimal fields. For serviceInstance, use that exact environmentId and a service belonging to that project. Both queries are documented, but the examples aren't a guarantee that every selected field is accessible to every token type. Separating them tells us which operation or field fails.

One useful distinction: Railway documents resolver authorization failures as HTTP 200 with a GraphQL errors array. An actual HTTP 403 alone doesn't establish that service or serviceInstance is unsupported. If the minimal projectToken request also returns 403, capture the Content-Type and inspect the body privately: is it GraphQL JSON or an HTML/text rejection? For JSON, retain the error's message, extensions.code and extensions.traceId; give Railway support the trace ID and your October 13 11:16 UTC timestamp. Don't post tokens, request headers or an unreviewed response dump.

Docs: https://docs.railway.com/integrations/api

Service queries: https://docs.railway.com/integrations/api/manage-services

AI-assisted; I checked these against Railway's current docs. I haven't accessed your account or reproduced your 403. Does projectToken by itself fail too?