Hi everyone,
I am currently testing a workflow on n8n Cloud (trial instance). I’m encountering a consistent getaddrinfo ENOTFOUND error when trying to reach api-crt.sabre.com using an HTTP Request node.
Things I’ve verified:
The domain is valid and reachable from my local network (I checked via ping and from other tools).
My n8n instance can successfully reach other endpoints like https://api.ipify.org or https://google.com, so it seems to have general internet access.
I am using the standard HTTP Request node with no proxy settings.
It seems like my n8n cloud instance might have issues resolving this specific domain (Sabre API). Could this be related to DNS restrictions or an outbound network filter on my specific instance?
Any guidance on how to troubleshoot this or if I need to adjust any specific network settings in the cloud environment would be greatly appreciated.
Thanks!
Welcome to the n8n community @Diego_Fuenmayor
So, based on what you reported, getaddrinfo ENOTFOUND indicates that the failure occurs before the HTTP request, during hostname resolution for api-crt.sabre.com. However, there isn’t yet enough information to conclude whether this is caused by n8n Cloud’s DNS environment, Sabre restrictions/allowlist, private/corporate DNS, or even specific characteristics of that endpoint. Before concluding, I would validate: whether the hostname resolves publicly (dig/nslookup); whether Sabre requires IP allowlist; whether the endpoint is partner/private-only; and whether the domain responds from other cloud environments outside of n8n.
@Diego_Fuenmayor easy one to verify before going deeper — the host doesnt resolve in public DNS at all. just ran dig against two public resolvers, dig +short api-crt.sabre.com @8.8.8.8 returns nothing, same against @1.1.1.1. both NXDOMAIN.
n8n Cloud uses public DNS, so getaddrinfo ENOTFOUND is the literal correct response — the hostname doesnt exist on the public internet. when u said it works from ur local network, ur either on a corporate VPN to Sabre, ur hosts file has an override, or ur ISP is doing split-horizon DNS. all three look like “valid domain” from ur side but n8n Cloud cant see any of them.
the public Sabre cert/test hostnames look more like:
{
"cert_rest": "https://api.cert.platform.sabre.com",
"prod_rest": "https://api.platform.sabre.com",
"sandbox": "https://api.test.sabre.com"
}
if api-crt was meant to be the cert REST env, swap to api.cert.platform.sabre.com and the lookup will succeed from n8n Cloud. if u genuinely need that exact internal hostname, n8n Cloud cant reach it — youd need to self-host n8n on infra thats inside ur VPN to Sabre, or front the call through a proxy thats already in that network.
A quick diagnostic that has saved me time on this exact class of issue: before assuming it is n8n Cloud’s DNS, confirm the hostname resolves outside n8n with the same public resolvers n8n Cloud almost certainly uses (Google 8.8.8.8 or Cloudflare 1.1.1.1).
From any terminal:
dig @8.8.8.8 api-crt.sabre.com
dig @1.1.1.1 api-crt.sabre.com
If one or both return NXDOMAIN or SERVFAIL while your local resolver returns an A record, the domain is likely only published on a private or split-horizon DNS that your local network sees but public resolvers do not. That matches the Sabre CRT (Certification) environment behaviour. Their CRT endpoints have historically been gated by allowlist and sometimes routed through Sabre-issued connectivity rather than the open internet.
If both 8.8.8.8 and 1.1.1.1 return an A record cleanly, then the issue is more likely on the n8n Cloud egress side and worth escalating with that dig output attached, because it shows the hostname is publicly resolvable everywhere except the instance.
One more thing worth checking: the production Sabre hostname (api.sabre.com) usually resolves publicly even when api-crt does not. If the prod hostname works from n8n Cloud and the CRT one does not, that is a strong signal it is a Sabre-side access boundary rather than n8n.