Sabre requires IP whitelisting for connection types such as Private Wire endpoints and legacy SOAP/GDS services. Route flight search, booking, and hotel API calls through two fixed static EU IPs so your travel integration keeps working from any platform.
Works with Sabre REST APIs, OAuth token flows, and booking platforms
import requests, os
# HTTPS_PROXY is set in the environment
r = requests.post(
"https://api.test.sabre.com/v2/auth/token",
data={"grant_type": "client_credentials"},
auth=(CLIENT_KEY, CLIENT_SECRET),
)
# token request leaves via your EU IP
Sabre requires IP whitelisting for connection types like Private Wire endpoints and legacy SOAP/GDS services. That requirement lands on your infrastructure.
Connections over Sabre's Private Wire network, along with legacy SOAP/GDS services, enforce strict IP filtering as baseline security. If your app's outbound IP keeps changing, the identity your Sabre integration presents is anything but trusted.
A Sabre workflow chains session or token creation, flight search, pricing, and booking into one sequence. Travel platforms that rotate egress mid-flow break the chain at the worst possible step, between search and confirmed booking.
Booking engines and agency tools increasingly run on PaaS and serverless platforms. Without a NAT gateway of your own, there is no fixed egress IP to give Sabre or partner agencies at all.
Sabre uses OAuth 2.0 access tokens that expire and renew. On horizontally scaled or serverless deployments, each renewal can originate from a different IP, which looks exactly like the credential-sharing pattern security teams block.
"Provide the IP addresses your integration will call from."
You need an answer that survives your next deploy.
Travel app
OutboundGateway
Two fixed EU IPs
Sabre API
Sabre sees one of your two fixed EU IPs, on every token request, search, and booking call.
Booking platforms integrating Sabre flights, hotels, and car rentals.
Products built on Sabre APIs that need a stable egress identity.
Itinerary and policy-compliance apps calling Sabre in the background.
Companies that must keep passenger-data traffic inside the EU.
Set the proxy once. Every Sabre REST call, including the OAuth token request, goes through it.
Sabre's REST APIs authenticate with OAuth 2.0. The token request, flight search, and booking calls all go through the proxy automatically once the env var is set.
# .env
HTTPS_PROXY=https://USER:PASS@eu-01.outboundgateway.com:8443
SABRE_CLIENT_KEY=your_key
SABRE_CLIENT_SECRET=your_secretimport requests, os
def get_sabre_token():
# requests reads HTTPS_PROXY from the environment
r = requests.post(
"https://api.test.sabre.com/v2/auth/token",
data={"grant_type": "client_credentials"},
auth=(os.environ["SABRE_CLIENT_KEY"],
os.environ["SABRE_CLIENT_SECRET"]),
timeout=30,
)
return r.json()["access_token"]📖 Full guide: for retries, timeouts, and session reuse, see the Python SSL proxy guide.
Attach an https-proxy-agent to your axios instance. Remember to URL-encode credentials if the password contains special characters.
import axios from "axios";
import { HttpsProxyAgent } from "https-proxy-agent";
const sabre = axios.create({
httpsAgent: new HttpsProxyAgent(process.env.HTTPS_PROXY),
});
const { data } = await sabre.post(
"https://api.test.sabre.com/v2/auth/token",
new URLSearchParams({ grant_type: "client_credentials" }),
{ auth: { username: process.env.SABRE_CLIENT_KEY,
password: process.env.SABRE_CLIENT_SECRET } }
);📖 Full guide: see the Node.js SSL proxy guide.
Load the proxy URL from a .env file so credentials never land in your image.
docker run --rm --env-file .env my-booking-appPassenger data and itinerary traffic deserve an egress that stays in EU jurisdiction.
Your proxy runs on infrastructure inside the European Union, so Sabre traffic stays within EU jurisdiction.
Data handling that aligns with European privacy expectations for travel and passenger data.
Traffic is not detoured through US-based servers, which keeps your compliance story simple.
Two fixed IPs give Sabre and partner agencies a stable, predictable answer about where requests originate.
A pair of static IPs with automatic failover. Allowlist once, keep booking.
requests, httpx, and axios all work through HTTPS_PROXY with no bespoke code.
Set the env var once. Sandbox, CI, and production all egress the same way.
No NAT gateway, no VPC changes, no custom networking. Just an environment variable.
TLS passthrough. Sabre credentials and passenger data are never decrypted by the proxy.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop fighting rotating egress IPs. Give your Sabre integration two fixed EU IPs today.
Yes, depending on your connection type. Sabre's documentation shows that connections over the Private Wire network and legacy SOAP/GDS services enforce strict IP filtering as part of their baseline enterprise security. Even on standard REST connections, security teams expect a trusted integration to come from a stable, allowlisted IP. OutboundGateway gives you two fixed EU IPs so your Sabre calls always originate from an allowlisted identity.
Yes. The OAuth 2.0 token endpoint is a normal HTTPS call, so with HTTPS_PROXY set, your token requests, flight searches, and booking calls all egress through the same two fixed EU IPs. That matters because token renewals from rotating IPs are exactly the pattern that looks suspicious to API security monitoring.
Yes. The proxy identity is independent of the Sabre environment, so the same two fixed IPs carry your traffic to both the test and production endpoints. That keeps your allowlisted identity identical across environments and makes the move from sandbox to live deployment one less thing to renegotiate with security.
We're happy to help you check whether OutboundGateway fits your Sabre workload.
Contact Our Team →