On the Hobby plan, outbound traffic uses shared egress IPs that are common across multiple customers, so it is very likely that Saxo/Akamai's WAF is blocking the IP range your requests originate from. We do not expose the specific shared egress IP used for a given request. Static Outbound IPs would give your service dedicated, consistent outbound IPs you could ask Saxo to allowlist, but this feature requires the Pro plan. Changing regions on Hobby would change the egress path but would still use a shared IP, so it is unlikely to be a permanent fix.

Thank you. This confirms our suspicion.

We tested the same Saxo OpenAPI Live OAuth flow outside Railway using a local Mac + ngrok redirect URL. The real authorization_code token exchange returned:

status: 201

content_type: application/json; charset=utf-8

The same token exchange from Railway returns:

status_code: 403

content_type: text/html

edge_blocked: true

Akamai / Access Denied

So this appears to be specific to Railway shared egress IPs being blocked or treated differently by Saxo/Akamai.

Could you please confirm:

1. If we upgrade to Pro and enable Static Outbound IPs, will our service get a dedicated outbound IPv4 for requests to https://live.logonvalidation.net/token?

2. Can Railway provide the actual current shared outbound IP used by our Hobby service, so we can pass it to Saxo support for confirmation?

3. Is there any way to temporarily test Static Outbound IPs or a different dedicated egress path before committing to a full migration?

4. Would changing Railway region on Hobby change the outbound IP range immediately, even if it is not a permanent fix?

We need a reliable outbound path for Saxo OpenAPI OAuth, because this is a financial API and Saxo/Akamai appears to block shared hosting egress.

Thank you.

Yes, on Pro with Static Outbound IPs enabled, your service gets permanent outbound IPv4 addresses (currently 3 IPs for HA) that you can provide to Saxo for allowlisting. Note that while these IPs are consistent and permanent for your service, the docs state there is no guarantee they won't be shared with other customers, though in practice they are far less likely to be WAF-blocked than Hobby shared egress. We do not expose the specific shared outbound IP used by Hobby services, so we cannot provide that for Saxo support. There is no way to temporarily test Static Outbound IPs without upgrading to Pro. Changing region on Hobby would change the outbound IP range, but it would still be a shared IP and subject to the same WAF blocking risk.

Thank you. This is helpful, but I still need confirmation from Railway support.

We performed a real OAuth Authorization Code test outside Railway using a local Mac + ngrok redirect URL.

Result outside Railway:

status: 201

content_type: application/json; charset=utf-8

The same Saxo OpenAPI token exchange from Railway returns:

status_code: 403

content_type: text/html

edge_blocked: true

Akamai / Access Denied

So the issue appears specific to Railway outbound egress.

Could you please confirm:

1. If we upgrade to Pro and enable Static Outbound IPs, will outbound requests from our service to https://live.logonvalidation.net/token always use the same static IPv4 address?

2. Can we see/copy the assigned Static Outbound IP after enabling it, so we can send it to Saxo Support for allowlisting/checking?

3. Is the Static Outbound IP shared with other Railway customers, or isolated for our workspace/service?

4. Is there any temporary way to test Static Outbound IPs before committing to a permanent migration?

5. Would changing region on Hobby only change to another shared egress IP range, meaning it is not a reliable fix?

This is for a financial API integration, so we need a reliable outbound path that Saxo/Akamai will not block.

Yes, with Pro + Static Outbound IPs enabled, all outbound traffic from your service will always use the assigned static IPv4 addresses (3 IPs for HA), including requests to live.logonvalidation.net. After enabling the feature in your service's Settings > Networking section, the assigned IPs are displayed right there in the dashboard for you to copy and share with Saxo support for allowlisting. Per our docs, there is no guarantee the IPs are fully dedicated (they may be shared with other customers), but they are permanent for your service and far less likely to be WAF-blocked than Hobby shared egress. There is no temporary trial for this feature, it requires a Pro upgrade. Changing region on Hobby would only move you to a different shared IP range, so it would not reliably resolve Akamai blocking.

Thank you. This confirms the shared egress IP issue.

Before upgrading to Pro, we need to understand whether Static Outbound IPs are likely to solve Saxo/Akamai blocking, because Railway says the IPs may still not be fully dedicated.

We have now confirmed:

• Railway → Saxo /token = 403 HTML Akamai Access Denied
• Local Mac + ngrok real OAuth code exchange → Saxo /token = 201 application/json

Could a Railway team member confirm whether Static Outbound IPs on Pro are shared or exclusive to our service/workspace, and whether Saxo can allowlist the assigned IPs reliably?

If Static Outbound IPs are still shared, we may need to move only the Saxo OAuth/token exchange layer to another provider with static/dedicated egress.

Per our docs, Static Outbound IPs are permanent for your service and will always be used for all outbound traffic, but there is no guarantee the IPs are fully dedicated to your workspace - they may be shared with other customers. That said, the feature is explicitly designed for third-party firewall allowlisting (MongoDB Atlas is the example in our docs), and the IPs are consistent and permanent, so Saxo can reliably allowlist them. There is no trial option, and upgrading to Pro is the only path to static egress.

Thank you. I understand that Static Outbound IPs on Pro are permanent for the service but not guaranteed to be fully dedicated.

Before upgrading, I would like a human Railway team member to confirm one point:

Our local Mac + ngrok real Saxo OAuth token exchange works and returns:

status: 201

content_type: application/json

The same request from Railway returns:

status_code: 403

content_type: text/html

Akamai / Access Denied

edge_blocked: true

Is there any known issue with Railway shared egress IPs being blocked by financial providers or Akamai/WAF systems?

Also, if we upgrade to Pro and enable Static Outbound IPs, can we immediately see the assigned outbound IPs in the dashboard and provide them to Saxo for allowlisting?

We need to decide whether upgrading to Pro is likely to solve this, or whether we should move only the Saxo OAuth/token exchange layer to another host with dedicated/static egress.

We don't track a list of providers that block our shared egress IPs, but shared cloud IPs being flagged by financial-grade WAFs like Akamai is a well-known pattern across hosting platforms. Static Outbound IPs on Pro are the feature we offer specifically for third-party firewall allowlisting, and yes, the assigned IPs are visible in your service's Settings > Networking section immediately after enabling, so you can copy them and send them to Saxo support. Per our docs, the IPs are permanent for your service but not guaranteed to be fully dedicated to your workspace. In practice, the risk of a static outbound IP triggering the same WAF block is significantly lower than shared Hobby egress, and Saxo can reliably allowlist the specific IPs you provide them.