Connect a Lovable Travel App to an IP-Allowlisted Hotel API

Your Lovable travel app can have a working interface and valid API credentials yet still fail to reach a hotel supplier. If the supplier restricts access by source IP, the missing piece may be the public address used by your backend.

That is not necessarily your website’s IP, your laptop’s IP, or the traveler’s IP. It is the outbound address of the server-side component making the request. Adding an IP address to a request field does not change that network source.

This article explains how to choose an appropriate route and verify it safely.

Start with the exact hotel API

“Bedbank” describes a type of travel supplier, not one API with a universal security policy. Confirm the provider, product, account, and environment before choosing an egress solution. Published requirements illustrate why that distinction matters:

• RateHawk / Emerging Travel Group APIv3 requires partner IP addresses for allowlisting. Confirm how that applies to your credentials and environment.
• TBO TekTravels’ HotelNew certification flow requests a static public or gateway IP after signoff. That is a product-specific requirement, not a verified rule for every TBO API.
• Hotelbeds’ CacheAPI Files Service uses IP-restricted access. Its Booking API security documentation separately requires mutual TLS for specified booking operations. A static IP does not replace a client certificate.

Ask whether the supplier accepts shared addresses or IP ranges, how many entries it permits, and whether sandbox and production have separate allowlists. Credentials, permissions, and supplier certification still apply.

Check whether Lovable already provides a suitable route

Lovable’s gateway-based custom connectors use fixed shared outbound IP ranges. If your supplier accepts those ranges and the connector supports the required requests, that route may already meet your needs. Custom connectors support Basic authentication, but authentication support alone does not prove compatibility with a complete supplier workflow.

Do not assume every request in a Lovable-built app goes through that gateway. An independently implemented backend function can have a different outbound route.

For example, hosted Supabase Edge Functions do not provide stable egress IPs. Supabase recommends an outbound proxy for services requiring IP allowlisting. If that is where your supplier calls run, QuotaGuard can provide a managed static-egress route without moving the whole app.

Keep the supplier connection server-side

The intended path is straightforward: your authenticated application operation calls a backend supplier client, which sends the request through QuotaGuard to the hotel API.

Keep supplier credentials and the QuotaGuard connection URL in server-side secrets. Never place them in browser code, public responses, screenshots, or logs. Authenticate and authorize the application operation, and do not expose an unrestricted proxy that accepts arbitrary destinations.

Configure the HTTP client actually making the supplier request. Merely adding a proxy environment variable does not prove that traffic uses it. For Supabase’s Deno runtime, follow the QuotaGuard Edge Functions guide and attach the configured client to the relevant fetch calls. Preserve the supplier’s required authentication and TLS behavior.

Standard QuotaGuard plans use shared infrastructure. If the supplier requires customer-exclusive addresses, evaluate dedicated infrastructure rather than assuming a standard plan qualifies.

Verify connectivity without making a booking

1. Get your assigned IP pair and exact connection URL from the QuotaGuard dashboard. Do not substitute an address obtained by resolving the proxy hostname.
2. From the deployed backend, run an IP-echo check through the same client that will call the supplier. Confirm the returned address matches your assigned pair.
3. Have the supplier approve both assigned addresses for the correct account and environment, even if one check shows only one address.
4. Use supplier-approved sandbox access and a documented, nontransactional authenticated request. Do not create, pay for, or cancel a reservation just to test connectivity.

If the observed IP is correct but access still fails, check credentials, permissions, environment, and the supplier’s specific error before assuming an IP problem. A single successful request does not validate every booking operation, retry path, or failover condition.

Choose the route your integration actually needs

Use the native connector route when it meets the supplier’s requirements. When your own backend needs managed static outbound IPs, start with the QuotaGuard Lovable integration overview and the runtime-specific setup guide. The goal is a verified server-side connection, not an extra networking layer for its own sake.