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.

flowchart TD A[Customer UI - Web / App] --> B[Hotel API Facade] B --> C[Hotel Blender / Orchestrator] C --> D[Markup, Discount, Promo Engine] C --> E[Payment Orchestration] C --> F[Parallel Supplier Search] F --> G[RateHawk - WorldOTA] F --> H[Hotelbeds - optional] F --> I[Local CRS - own inventory] G --> J[Shared CRS Content Database] H --> J I --> J

Responsibility split

Concern	RateHawk	Your platform
Live availability and price	SERP, hotel page, prebook	—
Rate lock (`book_hash`)	Prebook	Short-lived session cache
Photos, amenities, descriptions	Minimal in live API	CRS plus dump mapping
Markup, discounts, promos	—	Your commercial engine
Guest payment	—	Your payment gateway
Supplier settlement	Deposit or contract payment type	Align finish amount to contract
Final reservation	Form, finish, status	Called only after payment succeeds

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.

sequenceDiagram participant U as Customer participant P as Platform participant R as RateHawk API participant G as Payment Gateway U->>P: Search hotels (dates, guests, city) P->>R: SERP (geo or region) R-->>P: Hotel cards + result tokens U->>P: Select hotel P->>R: Hotel Page (HP) for hid R-->>P: Room list + book_hash U->>P: Select room, click Book P->>R: hotel/prebook (book_hash) R-->>P: New book_hash, adjusted price P->>U: Checkout page + payment URL U->>G: Pay G-->>P: Payment success P->>R: Booking form (open order) P->>R: Booking finish (guest + payment payload) R-->>P: Finish status (poll until ok) P->>U: Confirmation + voucher

Create a search session. Persist check-in, check-out, rooms, guests, nationality, and city, and return a search_id the UI can stream against.
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.
Hotel details. Serve name, gallery, amenities, and address from your CRS — keep RateHawk for rates, not brochure copy.
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.
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.
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.
Collect guest payment. Charge the traveler through your gateway first. Only confirm with RateHawk after payment succeeds.
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.
Confirmation and voucher. Fetch order info, store the supplier confirmation reference, and issue the voucher.

Key RateHawk API concepts

Concept	Role
SERP (geo / region)	Fast availability list for a destination
Hotel page	Full rate set for one hotel ID
`book_hash` / match hash	Identifies a specific rate; refreshed on prebook
Prebook	Locks availability; may adjust price within tolerance
Booking form	Opens an ETG order and returns payment types
Booking finish	Starts supplier-side confirmation, often asynchronous
Finish status	Polled until success or terminal failure
Order info / cancel	Post-booking retrieval and cancellations
Dumps	Region and hotel static content, typically compressed JSONL

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:

Region dump — map your cities to RateHawk region_id values
Hotel dump (full weekly plus daily incremental) — map RateHawk hid to your CRS hotel records
Promote staging to live CRS only after validation
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.

stateDiagram-v2 [*] --> SearchRequested SearchRequested --> ParallelSupplierSearch ParallelSupplierSearch --> RateHawkSERP ParallelSupplierSearch --> HotelbedsSERP ParallelSupplierSearch --> LocalCRSSearch RateHawkSERP --> Normalize HotelbedsSERP --> Normalize LocalCRSSearch --> Normalize Normalize --> Deduplicate Deduplicate --> ApplyMarkup ApplyMarkup --> UnifiedHotelList UnifiedHotelList --> [*]

The pattern that keeps this maintainable:

Register each supplier behind one provider interface — search, roomList, blockRoom, processBooking
Let the blender resolve active providers from your booking_apis configuration
Run SERP calls in parallel with an async HTTP client
Stamp every token with a booking_source flag
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:

Flow	Who pays whom	When
Guest payment	Traveler to your merchant account	Before Process Booking
RateHawk settlement	You to ETG, typically a deposit contract	On booking finish

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:

Poll finish status for a bounded window — tens of attempts, a few seconds apart
Treat retryable states like timeout or unknown as pending
Treat terminal states like soldout or hard charge errors as failures
On poll timeout, move to "awaiting confirmation" and hand off to a cron or worker
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

Pitfall	Symptom	Fix
Stale `book_hash`	Rate-not-found on form or finish	Always use the hash from prebook; keep block TTL short
Double prebook	Race conditions, expired locks	Don't re-call prebook at B2C checkout
Unmapped `hid`	Empty search results in a live city	Complete region and hotel mapping first
Sandbox geo mismatch	Zero SERP results	Search near documented sandbox anchors
Currency mismatch on finish	Charge or payment errors	Align sell amount and payment type currency
Ignoring price increase	Surprise amount at block	Handle `price_increase_percent` with a price-change UX
Sync-only confirm	False customer-facing failures	Add an awaiting status plus background poller
Auth on dump download	Dump fetch fails	Follow ETG's dump download rules — presigned URLs often shouldn't send Basic auth
Loading full dump in memory	Out-of-memory errors, timeouts	Stream compressed JSONL in batches

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.

multi-supplier hotel platform

RateHawk API Integration with Multiple Hotel Suppliers: A Complete Guide