Hi Railway Community & Team,

I'm using Railway extensively with N8N to automate server creation and management via the GraphQL API (`https://backboard.railway.app/graphql/v2`), and I'm consistently running into rate-limiting issues (Cloudflare Error 1015). It's becoming a real headache.

My typical workflow for a single server involves about five separate GraphQL API calls to set it up step-by-step (create service, connect image, create domain, configure, deploy). After that, I have a recurring poll request to check if the server is actually up and running. This pattern repeats for each server I manage.

The thing is, I'm not even spinning up a massive number of new servers every minute. Sometimes, I also need to delete services that didn't work out, and even those deletion attempts through the API can trigger rate limits. I've implemented retries in N8N – attempting an operation 5 times with a 5-second pause between each, so a single problematic operation can stretch out over 25 seconds – and I still hit the rate limit wall.

It feels like I'm getting blocked very easily, and I'm not just spamming pointless requests. An important detail is that these API requests are originating from an N8N instance running within the Railway network itself, not from an external IP.

My core question is: Is there a better way to handle this kind of automation with the Railway GraphQL API?

I'm essentially just trying to spin up servers, configure them, check their status, and delete them when necessary. I'm wondering if my multi-step approach or my polling strategy is the issue, or if this is an inherent characteristic of the API under these conditions. I'm honestly not sure how folks using Railway through IaC tools like Terraform manage these kinds of operations without hitting similar roadblocks.

Could someone from the team or the community shed some light on best practices here? Is this something I'm doing wrong, or is it just how the system works? If providing the internal IP of my N8N server would help, I'm happy to do that privately for potential whitelisting or investigation.

Any guidance on how to make this automation more robust and less prone to rate limits would be hugely appreciated.

Thanks!