18 days ago
Hello Railway Support,
I am reporting a possible Project Token issuance or authentication issue affecting one Railway project.
Project:
mellow-illumination
Environment:
production
Services in the project:
- bank-statement-converter
- bank-statement-automation-production
I created fresh Project Tokens from this exact location:
mellow-illumination → Project Settings → Tokens
For each token, the environment scope was explicitly set to production.
The request used Railway's documented Project Token authentication method:
- Endpoint: Railway Public GraphQL API
- Header name:
Project-Access-Token - Query:
query {
projectToken {
projectId
environmentId}
}
Observed timeline:
- 2026-08-03 approximately 13:38 HKT / 05:38 UTC
A newly created production-scoped Project Token successfully returned HTTP 200. Both projectId and environmentId were present.
- 2026-08-03 approximately 16:05 HKT / 08:05 UTC
A different newly created production-scoped Project Token returned HTTP 403 on the first projectToken request. No other API operation was attempted.
- 2026-08-03 approximately 16:25 HKT / 08:25 UTC
I performed a controlled recheck. I first verified the exact project, Project Settings → Tokens location, and production environment scope. A third newly created token again returned HTTP 403 on the first and only projectToken request.
Each temporary token was deleted immediately after its test. No request was retried. No GraphQL mutation, deployment, service modification, Variables query, or logs query was performed.
Could you please confirm:
- Whether there is a known or project-specific issue affecting Project Token issuance or authentication;
- Why fresh tokens from the same project/environment could previously return HTTP 200 but now consistently return HTTP 403;
- Whether Project Token API access for this project/environment requires repair or refresh by Railway;
- What safe, least-privilege recovery procedure you recommend before we attempt another Project Token.
For security, token values, request headers, resource IDs and private logs are intentionally omitted from this initial case. I can provide identifiers privately through a secure Railway support channel if required.
Thank you.
3 Replies
18 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 18 days ago
18 days ago
Hello Railway team,
I am following up because the thread currently contains only the automated
bounty/community-routing notice, and no substantive technical response has
been received yet.
Fresh Project Tokens created from this project’s Project Settings and
explicitly scoped to production previously authenticated successfully, but
two later newly created tokens both returned HTTP 403 on the first and only
documented projectToken read-only request.
Could a Railway employee or moderator please confirm whether this may be:
-
a Railway Project Token platform or issuance issue;
-
a project-specific authentication issue;
-
an account-tier or entitlement limitation; or
-
another documented requirement that applies to production-scoped Project
Tokens?
Before creating another token, we would appreciate a safe, least-privilege
recovery or verification procedure.
For security, token values, headers, resource identifiers, logs and private
project data are intentionally omitted. These should only be shared through a
private Railway-controlled channel if genuinely required.
No mutation, deployment or service configuration change was attempted.
Thank you.
kelvinlo817
Hello Railway team, I am following up because the thread currently contains only the automated bounty/community-routing notice, and no substantive technical response has been received yet. Fresh Project Tokens created from this project’s Project Settings and explicitly scoped to `production` previously authenticated successfully, but two later newly created tokens both returned HTTP 403 on the first and only documented `projectToken` read-only request. Could a Railway employee or moderator please confirm whether this may be: 1. a Railway Project Token platform or issuance issue; 2. a project-specific authentication issue; 3. an account-tier or entitlement limitation; or 4. another documented requirement that applies to production-scoped Project Tokens? Before creating another token, we would appreciate a safe, least-privilege recovery or verification procedure. For security, token values, headers, resource identifiers, logs and private project data are intentionally omitted. These should only be shared through a private Railway-controlled channel if genuinely required. No mutation, deployment or service configuration change was attempted. Thank you.
17 days ago
you should read it carefully and went over bounty AI and ask him to solve your problem. thankyou
kelvinlo817
Hello Railway team, I am following up because the thread currently contains only the automated bounty/community-routing notice, and no substantive technical response has been received yet. Fresh Project Tokens created from this project’s Project Settings and explicitly scoped to `production` previously authenticated successfully, but two later newly created tokens both returned HTTP 403 on the first and only documented `projectToken` read-only request. Could a Railway employee or moderator please confirm whether this may be: 1. a Railway Project Token platform or issuance issue; 2. a project-specific authentication issue; 3. an account-tier or entitlement limitation; or 4. another documented requirement that applies to production-scoped Project Tokens? Before creating another token, we would appreciate a safe, least-privilege recovery or verification procedure. For security, token values, headers, resource identifiers, logs and private project data are intentionally omitted. These should only be shared through a private Railway-controlled channel if genuinely required. No mutation, deployment or service configuration change was attempted. Thank you.
17 days ago
Is there any chance the production environment's ID changed at all between your two test windows — like a rename, recreation, anything touched in project settings? Since a 403 right away like that (before it even gets to resolver logic) usually means the token's pointing at something that no longer matches, even if the UI still shows it as scoped correctly.
Also worth checking if anything shifted on the account/workspace side between 13:38 and 16:05 HKT — plan change, billing thing, someone's access changing, project transfer, anything like that. Sometimes stuff like that quietly breaks token issuance even without anyone touching the token itself.
And less likely but — are you behind any shared IP or proxy? A 403 on literally the first request is a weird pattern for rate limiting but wouldn't hurt to rule it out.
None of this is something I can actually confirm from where I'm sitting, just the usual suspects when a token that worked suddenly doesn't with nothing obviously changed.