Your service has Under Attack Mode enabled, which aggressively challenges and rate-limits incoming requests at the edge, producing the 429s you're seeing. You can disable it in your service's settings under Settings > Edge > Under Attack Mode, and the 429s should stop immediately.

I can do this as workaround for now, but this is not the solution correct?

Disabling Under Attack Mode is the correct fix, not just a workaround. That mode is designed for use during an active DDoS incident, not as always-on protection. While enabled, it blocks all non-browser traffic outright (including curl and API calls), which is exactly why you're seeing 429s on most paths.

So how we allow legitimate traffic??? with turning On the Under Attack Mode

Under Attack Mode does not support selective filtering. While it is active, all non-browser traffic (curl, API clients, webhooks) is turned away with no exceptions. If your service serves an API, enabling it blocks 100% of API traffic. For selective protection, you can use Edge Rules instead, which let you match on source IP, path, host, or headers and then block, allow, challenge, or redirect per rule (your Hobby plan allows up to 3 rules per service). You will need to enable the "Edge Rules" feature flag at https://railway.com/account/feature-flags first, then configure rules under your service's Settings in the Edge section.