Hey there! We've found the following might help you get unblocked faster:

• 🧵 Increase API rate limit?

• 🧵 503 Error when using Railway with Terraform

• 🧵 Frequent GraphQL API Rate Limiting (Error 1015) with Multi-Step Server Creation & Polling / Deletion

If you find the answer from one of these, please let us know by solving the thread!

Hi there,

Could you please expand on the Cloudflare limit you're running into?

Additionally, have you considered batching requests?

Best,

The Railway Team

To expand on this, I’m consistently running into Cloudflare’s Error 1015 (“You are being rate limited”), documented here:

https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1015/

This appears to be the same underlying problem described in this Station thread:

https://station.railway.com/questions/increase-api-rate-limit-325de642

In that thread, a Railway employee identified the issue as being related to Cloudflare’s rate limiting, and an Internal ticket was referenced regarding it. Based on my experience, it seems that issue still isn’t resolved — the same Cloudflare blocking behavior persists.

To recap: this is not the 50 RPS limit defined by the Railway API. The block occurs at Cloudflare’s edge before the API responds, returning the following error:

Error: Client Error

│
│   with module.anglo.railway_project.anglo,
│   on modules/anglo/main.tf line 140, in resource "railway_project" "anglo":
│  140: resource "railway_project" "anglo" {
│
│ Unable to read project, got error: returned error 429 Too Many Requests: error code: 1015

When this block occurs, no X-RateLimit-* headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After) are returned — confirming that the requests are being stopped by Cloudflare before reaching the API.

HTTP/2 429
date: Thu, 23 Oct 2025 00:26:22 GMT
content-type: text/plain; charset=UTF-8
content-length: 16
retry-after: 86358
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
referrer-policy: same-origin
x-frame-options: SAMEORIGIN
server: cloudflare
cf-ray: 992d1a40bbd8197e-SOF
alt-svc: h3=":443"; ma=86400

If I temporarily change my IP to bypass the block, the same requests succeed and those headers appear again, showing plenty of available capacity — well below the documented API limit.

HTTP/2 200
date: Thu, 23 Oct 2025 00:17:04 GMT
content-type: application/json; charset=utf-8
vary: Origin, Accept-Encoding
access-control-allow-origin: https://railway.com
access-control-allow-credentials: true
x-ratelimit-limit: 1000
x-ratelimit-remaining: 987.2
x-ratelimit-reset: 2025-10-23T01:05:08.700Z
cache-control: no-store
via: 1.1 google
alt-svc: h3=":443"; ma=86400
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 992d0ca16b5ed0d7-SOF

A typical Terraform run performs 36 API requests over roughly 30 seconds, which is well below the documented 50 RPS threshold. Terraform’s concurrency model also makes batching difficult without undermining its core workflow. Additionally I don't see in the graphql schema any mechanism that would support batching requests on the Railway side either.

Would it be possible to adjust the Cloudflare thresholds to align with Railway’s documented API limits?

Alternatively, if the internal ticket referenced in that thread is still active, could you share an update on its status or any current mitigation plans?

This continues to be a major operational blocker for me, as Terraform integration is essential to my workflow.

Thanks very much,

Nathan

Hello,

Without an IP address to look up, it is hard to say what limit you are running into, but it is most likely the 10 RPS limit we apply to API requests that do not have a query string.

So please try adding a query parameter to your API calls, whether that is the mutation or query name, or your Railway workspace name.

Best,
Brody

I can confirm that the query parameter solves the issue. I have patched and submitted a PR to the terraform provider here: https://github.com/terraform-community-providers/terraform-provider-railway/pull/55 and have it working locally. Thank you for your assistance in finding the root cause.

I would encourage Railway to consider removing that restriction or at least documenting it. The graphql API does not typically include query parameters and I could not find anywhere that it was documented that such was necessary. With a 1 day ban for hitting the 10 query per second rate limit the behavior is substantially different than described in the API docs and I don't believe it is likely consistent with your intentions.

Glad that has worked for you, and your feedback has been noted!