Railway Support — 400 "Problem processing request" on GraphQL API from within a Railway-hosted service

Summary

A service I created in project CODENEST SERVER (service optimizer) calls Railway's own public GraphQL API (https://backboard.railway.com/graphql/v2) using an Account API Token. Every single call fails with HTTP 400 and body {"errors":[{"message":"Problem processing request","traceId":"..."}]} — but the exact same request, same token, same query, made from outside Railway's network (my laptop) succeeds every time with 200 OK.

What I've ruled out

Token validity: confirmed valid — works 100% of the time from outside Railway's network with this exact token value.

Token format/length: 36 characters, matches what's set in the service's RAILWAY_API_TOKEN variable (verified via railway ssh + printenv).

Rate limiting: x-ratelimit-remaining stays well above 9000/10000 the whole time — not exhausted.

CORS/WAF block: response headers show a genuine Cloudflare-fronted Railway backend response (server: cloudflare, cf-ray present, proper x-ratelimit-* headers) — the request reaches the real API, it isn't being blocked at the edge before reaching your app.

Auth header format: tried Authorization: Bearer alone, and combined with Project-Access-Token: — both fail identically.

Domain variant: tried both backboard.railway.com and backboard.railway.app — both fail identically.

Request concurrency: tried firing 3 GraphQL calls concurrently (Promise.all) vs strictly sequentially — both fail identically, and the very first call in a batch fails immediately every time (not a burst/rate issue).

Query correctness: the exact same query bodies work fine from outside — confirmed field-by-field against your GraphQL schema via introspection.

Token type: also created a second, project-scoped token (Project Token, "Environment: production" shown in the tokens table) and sent it via the correct Project-Access-Token header (confirmed this exact token+header combo returns 200 OK from outside Railway's network). From inside the same optimizer service, it fails with the identical 400 "Problem processing request" error. So this reproduces with both an Account Token and a Project Token — it isn't specific to one token type.

Environment

Node.js v24.10.0 (Railway's own Nixpacks build)

Native fetch (undici), no custom HTTP client

Project: CODENEST SERVER

Service: optimizer (service ID 86b7cf4e-8105-427a-8cec-ba83100c4d4b)

Environment ID: b5d1b409-4c66-400e-8531-834d9a4fdc5f

Tested with two token types, both fail identically from inside the service:

Account Token named "optimizer-service", scope shown as "djedumps's Projects" (default personal workspace), sent via Authorization: Bearer

Project Token (same name, scoped to "production" environment of this project), sent via Project-Access-Token

Example failing trace IDs (all within the last hour, same query)

Account Token attempts:

4524890407189790448

2634301957649095860

177003529870461187

9212787030237449922

6601124779106330487

362068177252923006

Project Token attempts (most recent, after switching token type):

6935580038495146170

9187751687768224796

9001749423565681326

7498477327354273550

1556801359765245101

Note: responses to the Project Token requests are missing the x-ratelimit-* headers that were present on the Account Token responses — the response shape itself differs slightly between the two token types even though both return the same generic 400 error, which might be a useful clue for your team.

Question

Is there a restriction on Account Tokens making calls to backboard.railway.com/backboard.railway.app from within a service hosted on Railway itself? Or is something about this specific token/account flagged? Any guidance on the correct way to call the public API from a Railway-hosted workload would be appreciated.