TBO Hotel API: Prepare Static Outbound IPs for Production

Getting a TBO hotel integration ready for production involves more than switching credentials. In TekTravels’ HotelNew certification process, the final networking handoff is the static public or gateway IP address from which your API requests reach TBO.

For an application running on a platform with changing outbound addresses, that handoff deserves its own deployment checklist. The goal is to give TBO an approved, predictable source address while keeping the application’s authentication and hotel workflow intact.

Start with the HotelNew certification requirement

TBO’s HotelNew certification instructions place IP allowlisting after test-case review, API validations, portal verification, and signoff. Live access and the source-IP handoff are related steps, not substitutes for one another.

Use the onboarding instructions assigned to your account. This article focuses on that HotelNew documentation, whose FAQ includes TBO India-specific rules. Do not assume every TBO product, regional program, or hotel API follows an identical authentication or allowlisting process.

Before changing the application, confirm the approved production endpoints, credentials, allowed source addresses, and whether staging has a separate allowlist. Ask whether shared proxy addresses are accepted and how many addresses can be registered. Those details determine the right network setup.

Do not confuse EndUserIp with the connection’s source IP

The HotelNew Authenticate reference includes an EndUserIp field described as the public server IP. That field is data inside the request. Setting it does not change the address from which the network connection arrives.

If a backend connects directly from a changing cloud address, putting a static address into JSON does not route that request through the static address. Configure the outbound connection separately, and populate any required IP field according to TBO’s instructions for the particular method and account.

Keep the authentication flows separate, too. The HotelNew Authorization page describes Basic authentication over HTTPS for hotel methods, while Authenticate documents a token response. Follow the requirements of each endpoint you actually use rather than adding a token or copying a payload from another method.

Route the deployed TBO client through stable egress

QuotaGuard provides an outbound proxy route with two assigned static IPv4 addresses. Standard subscriptions use shared infrastructure; if TBO requires customer-exclusive addresses, evaluate an Enterprise dedicated configuration instead. Your application keeps calling the approved TBO HTTPS destination, but its configured HTTP client sends the connection through the proxy.

Keep the proxy URL and TBO credentials in protected server-side configuration. Do not expose either in browser code, public responses, or logs. A proxy environment variable alone is not enough if the HTTP library ignores it: apply the proxy configuration to the client that performs the TBO requests.

Use the setup guide for your runtime, such as the Python proxy guide or Supabase Edge Functions guide. Include background jobs and separate workers in the review. A correctly routed web request does not prove that a scheduled hotel-data refresh uses the same client.

Hand over both assigned addresses, not your website’s IP

Copy the two addresses from your QuotaGuard dashboard. These are the addresses to discuss with TBO for the proxied route, not your website’s DNS address, your laptop’s current address, or an IP found by resolving the proxy hostname.

Register both assigned addresses where TBO permits the pair. QuotaGuard’s normal route is load balanced, so checking one request may reveal only one address. If your account permits only one, review the single-IP configuration and its failover tradeoff before choosing that approach.

From the deployed backend, run an IP-echo check through the same configured client and confirm that the result matches the assigned pair. Then use an approved, non-booking request in the correct TBO environment to check authentication and access. Do not create or cancel reservations merely to diagnose networking.

Keep production access checks separate from booking behavior

If access still fails, inspect the actual HTTP and API response before changing the allowlist again. Check the endpoint, credentials, account permissions, required fields, and observed outbound IP independently. A static IP fixes source-address consistency; it does not grant production access or repair an invalid hotel request.

TBO also documents a limited staging-access period after live credentials are released. Plan production readiness and later testing access with your TBO team rather than assuming staging remains available indefinitely.

For a managed outbound route, start with your QuotaGuard dashboard and the appropriate runtime guide. Finish with an approved source-IP pair, correctly authenticated requests, and a deployment configuration that keeps both aligned.