Building a hotel product today takes more than plugging into one supplier and hoping coverage holds up. Travelers expect deep inventory, competitive rates, and a reliable path from search to voucher. RateHawk — Emerging Travel Group's (ETG) WorldOTA B2B API — is one of the fastest ways to get that coverage, because a single contract puts you behind a genuine multi-supplier hotel network.

This guide walks through how RateHawk API integration works in a production travel platform, what "multiple hotel suppliers" actually means at two different layers of the stack, and how to design a booking flow that stays fast, accurate, and operable at scale — the same architecture our team at Teenva AI builds for OTAs, TMCs, DMCs, and travel agencies.

Why RateHawk matters for multi-supplier hotel platforms

RateHawk's WorldOTA B2B v3 API lets partners search live availability, lock rates, and confirm bookings against a large hotel catalog sourced from ETG's network of underlying suppliers and direct hotel partners. For platform builders, that translates into a few concrete wins:

• One integration instead of a dozen separate supplier connectors

• Broad global coverage at competitive B2B rates

• A standardized booking lifecycle — search, hotel page, prebook, form, finish, status

• Static content dumps for regions and hotels, so you can build your own content database instead of depending on a live API for brochure copy

RateHawk does not replace your product layer. You still own search UX, markup, payment, vouchers, and support. What it removes is the need to negotiate and maintain a separate hotel API for every inventory source on day one.

Two layers of "multiple hotel suppliers"

When platform teams talk about RateHawk API integration with multiple hotel suppliers, they're usually describing one of two patterns — or both at once.

Vertical aggregation, inside RateHawk

RateHawk itself behaves as a meta-supplier. When your platform calls booking/finish, ETG routes the reservation to the correct underlying supplier or hotel partner behind the scenes. You never call those partners directly, and confirmed orders typically carry supplier-scoped references inside the response payload.

Horizontal blending, on your own platform

Mature travel platforms usually run more than one live hotel source in parallel — RateHawk alongside Hotelbeds, or a private CRS, or both. A blender layer sits in front of all of them:

• Fans a single search request out to every active hotel API

• Normalizes each supplier's response into one common hotel-card format

• Deduplicates properties against a shared content database

• Routes every later step — room list, block, book — using a booking_source flag carried on the rate token

The practical takeaway: treat RateHawk as your primary aggregator, but design the platform so a second or third supplier can be added later without rewriting the B2C controller.

Architecture that holds up in production

A durable hotel architecture keeps three concerns cleanly separated: live rates, static content, and commercial rules.

Responsibility split

Keeping this split explicit is what stops business logic from leaking into what should be thin HTTP adapters.

Authentication and configuration

RateHawk B2B calls typically use HTTP Basic Auth:

• Username — API key ID

• Password — API key access token

• Base URL — WorldOTA API host, sandbox or production, usually ending in /api

Credentials belong in a secure, admin-managed booking-API configuration store, never in frontend environment files. Log every request and response against the booking API ID so support and chargeback investigations have a trail to follow.

You'll also need to configure:

• Request currency — what you send on SERP, hotel page, and prebook calls

• Display / base currency — what customers and finance actually see

• Prebook price increase percent — how much rate drift you'll tolerate when locking a rate

Sandbox tip: geo search is often restricted to a handful of documented test anchors. Check those before assuming your city mapping is broken.

End-to-end booking flow

A production-safe RateHawk journey generally follows nine steps.

1. Create a search session. Persist check-in, check-out, rooms, guests, nationality, and city, and return a search_id the UI can stream against.

2. Search (SERP). Call RateHawk's region or geo SERP — prefer geo when lat/lng is reliable, otherwise fall back to a mapped region_id. Attach an opaque result token carrying supplier code, hotel ID (hid), dates, guests, and rate key. If you run a CRS, skip hotels that aren't mapped yet; a live rate with no name or photos is a broken UX.

3. Hotel details. Serve name, gallery, amenities, and address from your CRS — keep RateHawk for rates, not brochure copy.

4. Room list (hotel page). Call hotel page for that hid, group rates by room type, and expose board, cancellation, and price variations, each carrying its current book_hash.

5. Block room (supplier prebook). Call hotel/prebook with the current hash and an allowed price_increase_percent. Prebook returns a new book_hash and may adjust the price — cache the blocked snapshot for a short window, roughly 45 minutes, so checkout stays consistent.

6. PreBook on your platform (checkout). Create booking rows, store guest details, compute the final quote with markup and fees, and generate a payment URL. Most B2C platforms deliberately skip a second RateHawk prebook here, since the supplier lock already happened at Block Room and a second call can race or double-lock.

7. Collect guest payment. Charge the traveler through your gateway first. Only confirm with RateHawk after payment succeeds.

8. Process booking (form, finish, status). Open the ETG order with partner_order_id and book_hash, send the guest and payment payload on finish (often payment type deposit), then poll finish status until it reaches ok or a terminal error. On long confirms, move the booking to "awaiting confirmation" and let a background job keep polling instead of failing the customer immediately.

9. Confirmation and voucher. Fetch order info, store the supplier confirmation reference, and issue the voucher.

Key RateHawk API concepts

Guest rules. RateHawk enforces limits on adults, children, and child age ranges per room — validate these on your search form so you never send an invalid SERP payload.

Residency and nationality. Map guest nationality to RateHawk's residency code carefully; getting it wrong can change both eligibility and price.

Static content, dumps, and hotel mapping

Live APIs make poor brochure databases. Production systems download RateHawk's dumps and map them into a local CRS:

1. Region dump — map your cities to RateHawk region_id values

2. Hotel dump (full weekly plus daily incremental) — map RateHawk hid to your CRS hotel records

3. Promote staging to live CRS only after validation

4. Stream large dumps — hotel files can run multiple gigabytes, so use batching or streaming workers rather than loading everything into memory

Without mapping, unmapped hotels stay hidden by design, block room can fail if a mapping disappears between search and checkout, and cross-supplier deduplication becomes effectively impossible. A useful cross-catalogue trick is promoting hotels on a stable key — name, star rating, and region — so the same property from RateHawk and another supplier collapses into a single CRS hotel with multiple supplier maps.

Blending RateHawk with other suppliers

If RateHawk is already integrated, adding Hotelbeds or a private CRS shouldn't mean forking your controllers.

The pattern that keeps this maintainable:

1. Register each supplier behind one provider interface — search, roomList, blockRoom, processBooking

2. Let the blender resolve active providers from your booking_apis configuration

3. Run SERP calls in parallel with an async HTTP client

4. Stamp every token with a booking_source flag

5. Apply markup and discount logic after normalization, so commercial rules stay supplier-agnostic

To the customer, it's one hotel list, one details page, one checkout. Behind the scenes, the rate token decides whether the next call goes to RateHawk, Hotelbeds, or your own CRS — which is exactly how "multiple suppliers" turns from an engineering tax into a product advantage.

Pricing, currency, and commercial rules

A clean pricing pipeline generally has four layers: supplier net or sell components from RateHawk's payment options, a tax breakdown separating included taxes from pay-at-property extras, your platform's markup and promo logic, and a final display conversion into the customer's currency.

On finish, the amount sent as the partner sell amount has to align with the chosen RateHawk payment type and currency — misalignment is one of the most common causes of charge-related failures. Always surface cancellation policy and meal-plan flags from the rate row; they're conversion drivers, not footnotes.

Payments vs. RateHawk settlement

These are two separate money movements and should never be confused:

Most B2C builds use RateHawk's deposit payment type. Contracts using immediate card capture (now) typically need a valid return path and different handling on finish. Never confirm a RateHawk booking before your gateway reports success, outside of a controlled QA bypass environment.

Async confirmation and cancellations

Supplier confirmation isn't always synchronous, so a resilient process should:

1. Poll finish status for a bounded window — tens of attempts, a few seconds apart

2. Treat retryable states like timeout or unknown as pending

3. Treat terminal states like soldout or hard charge errors as failures

4. On poll timeout, move to "awaiting confirmation" and hand off to a cron or worker

5. Persist both the partner order ID and the RateHawk order ID for support

For cancellations, call RateHawk's cancel endpoint with the partner order ID, store penalty amounts, and mirror the resulting status into your booking tables and vouchers.

Production best practices

• Opaque tokens — never expose raw hashes or guest payloads to the browser unsigned

• One prebook per checkout — Block Room owns the RateHawk lock; checkout PreBook owns your database and payment link

• Stream search results — chunked responses feel faster than waiting for every supplier to finish

• Log everything — full request/response history per booking API is non-negotiable for disputes

• Map before you sell — no CRS mapping, no card shown on the SERP

• Background dump workers — weekly full plus daily incremental hotel dumps

• An awaiting poller — never leave "stuck confirming" bookings without an owner process

• Sandbox realism — test geo constraints, price drift, sold-out paths, and slow confirms

• Provider isolation — the RateHawk adapter should only do HTTP and normalization; the blender owns commerce logic

• Idempotent partner order IDs — generate once, reuse safely on retries

Common pitfalls and how to avoid them

FAQ

Is RateHawk a hotel supplier or an aggregator? Both, from a product standpoint. You integrate one RateHawk API, and RateHawk fulfills bookings through multiple underlying suppliers and hotel partners.

Can I use RateHawk together with Hotelbeds or my own CRS? Yes — use a blender layer with parallel search, shared CRS content, and tokens carrying a booking_source flag so later steps route correctly.

Which RateHawk endpoints are required for a full booking? At minimum: SERP or hotel page search, hotel page, prebook, booking form, booking finish, and finish status. Add order info and cancel for post-booking operations, plus dumps for content mapping.

Why does prebook return a new hash? RateHawk re-validates the rate at that point. The new book_hash is what you must send to booking form and finish — treat the old hash as consumed.

Should guest payment happen before or after RateHawk finish? Before. Collect payment through your gateway first, then confirm with RateHawk, so you never create an unpaid supplier reservation.

How do I keep hotel content rich if the live API is thin? Download RateHawk's region and hotel dumps, map hid values into your CRS, and serve details from your database while rates stay live.

What happens if confirmation takes too long? Poll for a bounded time, then move to an awaiting state and continue with a scheduled worker rather than failing the booking just because the supplier is slow.

Conclusion

RateHawk API integration is one of the highest-leverage moves a hotel platform can make: a single B2B contract unlocks a multi-supplier inventory network, while your blender, CRS, payments, and commercial rules stay fully under your control. Separate live rates from static content, follow the proven path from SERP through prebook to form, finish, and status, and design for horizontal supplier blending even if RateHawk is your first live source. Get the dumps, mapping, logging, and async confirmation right early, and "multiple hotel suppliers" stops being an integration headache — it becomes the inventory advantage your customers feel on every search.

Need help integrating RateHawk or blending multiple hotel suppliers into your travel platform? Teenva AI & Digital Ventures builds API integrations for OTAs, TMCs, DMCs, and travel agencies. Reach out at sales@teenvaai.com or +91 9572020107.