A hotel repricing API re-checks a confirmed refundable hotel booking for a lower price on the exact same room, then books the cheaper rate and cancels the original before the free-cancellation deadline. Tripgic is a unified travel API that aggregates 2M+ hotel properties from 50+ suppliers, and its standard Hotel API calls cover every step of the repricing loop.

So, is there a hotel API that can re-check a booked refundable hotel and rebook it automatically? Yes. The automation is a scheduled job that you run on the API’s search, price-check, book and cancel calls, under your own rules. A ready-made monitoring tool is the other route, covered later in this guide.

This is a practitioner’s guide to building that job. Tripgic’s hotel repricing API page summarises the loop; this guide goes deeper into the parts that decide whether repricing earns money or causes complaints: which bookings qualify, how to match the same room across suppliers, how to calculate the net saving, how often to re-check, and the risks around cancellation deadlines, rate rules and the traveller. It ends with build-versus-buy options and a launch checklist.

What Is Hotel Repricing? An Illustrative Example

The numbers below are an illustrative example, not a measured result. A traveller books a refundable Deluxe King room with breakfast for three nights at EUR 186 a night, free cancellation until two days before arrival. Ten days later the same room, same board, same occupancy and same cancellation terms appears at EUR 159 a night.

A hotel repricing job notices the drop, books the new rate, confirms it, and then cancels the original booking at no charge. The gap is EUR 27 a night, or EUR 81 across the stay, before costs. The traveller sleeps in the same room. The seller either keeps the difference as margin or hands it back.

That is the whole idea. Everything else in this guide is about doing it safely and at scale: finding the drop, proving it is really the same room, acting before the deadline, and making sure the saving survives fees.

Repricing goes by several names. Re-shopping, rebooking, price-drop rebooking, post-booking rate optimisation and hotel price assurance all describe the same job. This guide uses “repricing” throughout.

Why Do Hotel Prices Drop After Booking?

A hotel price is not fixed once you book it. Several forces move it, and some of them push rates down before arrival:

  • Dynamic pricing. Most hotels now price dynamically, which Cloudbeds describes as adjusting rates and stay restrictions in response to changes in local demand and market conditions. When bookings for a date come in slower than planned, a hotel can lower rates to fill rooms.
  • Unsold inventory near arrival. Rooms that are still empty close to the date may be released at lower rates, sometimes through wholesale channels.
  • Different suppliers, different nets. The same room reaches resellers through bedbanks, wholesalers, chain connections and regional suppliers. Each one has its own contract and its own net rate, and those nets can move independently. Our bedbank API guide explains how that wholesale layer works.
  • Promotions and short-lived rates. A flash sale, a member rate or a regional promotion can undercut the rate you booked for a few hours or days.

How often a refundable booking actually gets cheaper depends on the market, the lead time and how many of your bookings are refundable, so measure it on your own bookings before you build a business case on it. What makes it catchable is the free-cancellation window, which gives the seller time to act. An aggregated hotel API helps because one search returns the same property from many suppliers in one response, so a drop on any of them is visible without separate integrations. Our guide to multi-supplier travel inventory explains why that breadth matters.

Who Uses Hotel Repricing?

Hotel repricing pays off for any business that holds refundable hotel bookings over time. The motive differs by business:

Business What repricing does for it Who usually keeps the saving
OTA Adds margin on bookings already sold, without raising the price the traveller saw The OTA, as margin
B2B portal or wholesaler Lowers the net cost of rooms sold to agents, so the portal can hold its selling price The portal, or shared with agents
TMC or corporate booking tool Cuts hotel spend for the client company and supports travel policy price caps The client company
Loyalty or rewards platform Lowers the cash cost of a points redemption The programme, or the member as points
Bank or fintech travel feature Turns a booking into a recurring value moment for the cardholder The cardholder, as a refund or credit

The business case is strongest where three things meet: enough refundable bookings, a lead time of days or weeks between booking and arrival, and markets where hotel rates actually move. A platform selling mostly same-week, non-refundable stays will find few opportunities. A corporate tool booking conferences months ahead has far more time for a rate to move.

If you run a corporate tool, read our corporate travel API guide for how hotel data fits travel policy. OTAs can start with travel API for OTAs. Rewards teams can see how repricing fits points redemptions in our guide to the travel API for loyalty programs, and banks and fintechs can start with the embedded travel API.

How Does Hotel Repricing Work, Step by Step?

Hotel repricing works as a scheduled job that loops over refundable bookings until each one passes its free-cancellation deadline. On every pass the job re-searches the same stay, keeps only offers for the identical room and terms, re-confirms the cheapest one, books it, and cancels the original only after the new booking is confirmed. The six steps are:

  1. Pick candidates. List confirmed bookings that are refundable and still before their free-cancellation deadline, minus a safety buffer.
  2. Re-shop. Search the same property for the same dates and room mix, and list the property’s current rooms and rate plans.
  3. Match like for like. Keep only offers with the same room type, board, occupancy and dates, and with equal or better cancellation terms.
  4. Confirm the price. Re-validate the cheapest matching offer and its cancellation policy right before acting, because search prices can be cached or stale.
  5. Book the new rate. Create the new reservation, issue its voucher and confirm it succeeded.
  6. Cancel the original. Only after the new booking is confirmed, cancel the old one under its free-cancellation terms, then tell the traveller.

The order of steps 5 and 6 is the most important design decision in the whole system. If you cancel first and the cheaper rate is gone by the time you try to book, the traveller has no room. If you book first and the cancellation then fails, you hold two bookings for a short time, which is fixable before the deadline.

Which API Calls Does a Repricing Loop Use?

On an API, each of those six steps maps to calls you already use in a normal booking flow. Here is the mapping on Tripgic’s Hotel API, as published on its repricing page:

Step Tripgic Hotel API call What your job does
1. Pick candidates /hotel/booking-details Read each booking’s status, rate plan and free-cancellation deadline
2. Re-shop /hotel/search · /hotel/rooms Search the same property, dates and room mix; list current rooms and rate plans
3. Match like for like (your logic) Filter to the same room type, board, occupancy and equal or better cancellation terms
4. Confirm the price /hotel/validate Re-confirm the cheaper rate and its cancellation policy just before acting
5. Book the new rate /hotel/create · /hotel/issue-voucher Create the new reservation and issue its voucher
6. Cancel the original /hotel/cancel-booking Cancel the old booking only after the new one is confirmed

Two details make this practical. First, every Tripgic hotel call is a POST that returns the same JSON envelope, whichever supplier fulfils the room, so the job does not need per-supplier parsing. Second, cancellation rules come back structured per rate plan, with the deadline, the penalty amount and its currency, so the job can compare terms as data rather than reading free text.

Guest details for the new booking go through /hotel/update-travellers, the same call your normal flow uses. The full flow and field-level detail are on the Hotel API page and in the API documentation once you have sandbox credentials.

The Decision Rule Behind Every Rebooking

The repricing job applies one rule to each candidate booking. Written as pseudo-code, with the matching API step in each comment, it looks like this:

for booking in refundable_bookings():                    # booking details
    if now() > booking.free_cancel_until - SAFETY_BUFFER:
        continue                                         # too close to the deadline
    offers = reshop(booking.hotel, booking.dates, booking.rooms)   # search + rooms
    matches = [o for o in offers
               if same_room(o, booking)                  # mapped room record, not the name
               and o.board == booking.board
               and o.occupancy == booking.occupancy
               and o.refundable
               and o.free_cancel_until >= booking.free_cancel_until]
    if not matches:
        continue
    offer = price_check(cheapest(matches))               # validate: live price and terms
    if not offer.still_matches(booking):
        continue                                         # price or terms moved; next run
    saving = booking.total - offer.total - costs(offer)
    if saving < MIN_SAVING:
        continue
    new = book(offer)                                    # create + issue voucher, first
    if not new.confirmed:
        continue                                         # original stays untouched
    if cancel(booking).ok:                               # cancel booking, second
        notify_traveller(new)
    else:
        retry_then_alert_support(booking)                # must finish before the deadline

Three settings control the behaviour, and each is a business decision, not a technical one:

  • SAFETY_BUFFER — how long before the deadline the job stops acting. It must cover the time to book, confirm, retry and cancel, plus any doubt about which time zone the deadline uses.
  • MIN_SAVING — the smallest net saving worth a rebooking. It filters out tiny moves that create churn for guests and hotels.
  • costs(offer) — one number that sums everything the rebooking costs you: the markup on the new booking, any charge on the cancelled one, payment costs, and a share of the search traffic spent finding drops, spread across all re-checks. The next section breaks it down.

How Do You Calculate the Real Saving From Hotel Repricing?

The real saving from hotel repricing is the original booking total minus the new total, minus every cost the swap creates: any charge on the cancelled booking, the provider fee on the new one, payment costs and the search traffic used to find the drop. The price gap alone overstates the result, and a job that ignores those costs can lose money on every swap. Use this formula:

Net saving = original total − new total − charge on the cancelled booking − provider fee on the new booking − payment costs − search cost

Back to the illustrative example: three nights, EUR 186 down to EUR 159 a night.

Line Amount Note
Original total EUR 558 3 × 186
New total EUR 477 3 × 159, re-confirmed by price check
Gross gap EUR 81 Before any cost
Charge on cancelled booking EUR 0 Cancelled inside the free window
Provider fee on new booking 3 × your per-night markup Charged again, because the rebooking is a new booking
Payment costs Depends on your setup Card fees, currency conversion, refund handling
Search cost Small per check Each re-check uses search traffic under your look-to-book ratio

Two of those lines are easy to forget. With a provider that charges a flat fee per room night, the rebooking is a new booking and carries the fee again. And if the traveller paid by card, refunding the old charge and taking a new one can cost card or currency fees that eat a small saving.

The practical answer is a MIN_SAVING threshold set above the sum of those costs, plus a margin for the support time the odd failure takes. On Tripgic, each successful rebooking counts as a new booking with its own flat per-night markup, so the repricing page advises setting the minimum saving above that markup. Current figures are on the pricing page; our guide to travel API pricing models explains how flat markups, commissions and per-call pricing affect margin.

How Do You Match the Same Hotel Room Across Suppliers?

You match the same hotel room across suppliers by mapping every supplier’s room names to one internal room record, then comparing hotel, room type, bed type, board, occupancy, dates, cancellation terms and rate conditions field by field. A cheaper rate is only a saving if it buys the same product, and room matching is where most repricing errors start, because suppliers describe one room in different words. “Deluxe King”, “King Deluxe Room” and “DLX KNG” may be one room or three.

Check each attribute before accepting a match:

Attribute Must match Common trap
Hotel Same property Two properties in the same chain and city with similar names
Room type Same room category Sea-view swapped for garden-view, or a smaller room type with a similar name
Bed type Same, if the guest requested it King swapped for twin when the guest asked for one bed
Board basis Same meal plan Breakfast-included replaced by room-only
Occupancy Same adults and children A rate priced for one adult used for two
Dates Same check-in and check-out A rate for a shorter stay matched by mistake
Cancellation terms Equal or better A refundable rate swapped for a non-refundable one
Rate conditions Allowed for your sale Member-only or package-only rates sold standalone

Normalise before you match: compare room records, not strings. On an aggregated API, part of this work is done for you, because the response arrives in one schema whichever supplier fulfils it. Room names still differ by supplier, so keep a mapping layer. Our guide to hotel room mapping covers property, room and rate mapping step by step, including how to score a match.

When in doubt, skip. A missed saving costs a little margin. A downgraded room costs a complaint, a refund and possibly the customer.

How Close to the Cancellation Deadline Can You Rebook?

A hotel repricing job should stop acting a safety buffer before the free-cancellation deadline, often about a day, so that booking, confirming, retrying and cancelling all finish in time. After the deadline passes, cancelling the original costs a penalty, often the first night or the whole stay, and the saving disappears. The deadline is the hard edge of repricing.

Four rules keep a repricing job on the safe side:

  • Store the deadline as data. Read it from the booking’s structured cancellation policy, not from a text description. On Tripgic, every rate plan carries structured rules with the deadline, penalty amount and currency.
  • Know the time zone. Hotels often state deadlines in local time. Convert to one standard, such as UTC, before comparing with your server clock.
  • Stop early. Set a safety buffer, such as a day before the deadline, after which the job no longer acts on that booking. The buffer covers retries, slow responses and the time support needs if something fails.
  • Never accept worse terms. The new rate’s free-cancellation deadline should be the same or later than the original’s. A cheaper rate with an earlier deadline shortens your future options and the traveller’s flexibility.

The last days before the deadline are also when unsold rooms are most likely to be discounted. That is why many teams re-check more often then, while still respecting the buffer.

Which Hotel Rates Can You Rebook Into?

A lower price that appears in a search is not always a rate you are allowed to sell in that situation. Hotels and suppliers attach conditions to many rates, and a repricing job must respect them.

Watch for these rate types:

  • Member or loyalty rates that require the guest to be enrolled in a programme.
  • Package rates that may only be sold together with a flight or another product.
  • Opaque or private rates with display or resale restrictions.
  • Geo-targeted rates that apply only to guests from a certain country.
  • Non-refundable or advance-purchase rates, which fail the cancellation rule anyway.

Rate parity also matters to hotels. Cloudbeds defines rate parity as keeping a hotel’s publicly available rates the same across all distribution channels, and it is set by contracts between hotels, OTAs and other booking platforms. A drop that comes from a short parity break or a restricted rate may be withdrawn or challenged. Your job should take only rates that are bookable for your sale under the rules returned with the offer.

Tripgic’s repricing page says it plainly: some rates carry conditions on rebooking, so respect the rate rules returned with each offer and your agreement with Tripgic. In practice, filter on rate-plan type during matching and log the rate conditions of every rebooking for audit.

How Often Should a Hotel Booking Be Re-checked?

About once a day per eligible booking is a common pattern for hotel repricing, with more frequent checks in the last few days before the free-cancellation deadline. Every re-check is a hotel search, and searches cost something: provider look-to-book limits, your own infrastructure, and sometimes per-call fees. The right cadence balances the chance of catching a drop against that cost.

The table below is an illustrative starting point, not a benchmark. Tune it against your own opportunity rate once the pilot is running:

Time until free-cancellation deadline Re-check frequency Why
More than 30 days Every 2–3 days Lower urgency; plenty of passes still to come
7–30 days About once a day The common pattern for most bookings
2–7 days Two or more times a day Last chance to catch discounted unsold rooms
Inside the safety buffer Stop Too close to act safely

Tripgic’s repricing page suggests checking each eligible booking about once a day, more often in the last few days before its cancellation deadline, and skipping stays that are already non-refundable or too close to the deadline. Re-check searches count toward your search allowance on Tripgic, so the cadence is also a budget decision; details are on the pricing page.

Prioritise by value. A ten-night stay at a city-centre hotel has more to gain than a one-night budget room. Rank candidates by booking total and time left, and spend search traffic where the expected saving is largest.

How Do You Protect the Traveller When a Booking Changes?

A rebooking the traveller never notices is a good rebooking. A rebooking that breaks their arrival is a disaster. Plan for the traveller from the start:

  • Send the new confirmation at once. A rebooking creates a new voucher and confirmation number. Send it straight away and keep the old reference on file, so support can answer “which booking is real?”
  • Carry over special requests and guest details. Bed-type requests, late-arrival notes, accessibility needs and loyalty numbers must be re-sent with the new booking, and guest names copied from the original record, never retyped.
  • Sync downstream systems. For TMCs and corporate tools, update the trip record so duty-of-care and expense systems point at the live booking.
  • Say it in your terms. Your terms and conditions should state that you may replace a refundable booking with an identical cheaper one, and who keeps the saving. Tell the traveller clearly when it happens.
  • Exclude sensitive bookings. Allow a flag to skip repricing for VIP guests, group blocks, bookings with complex requests or bookings close to arrival.

A good rule of thumb: if a traveller would need to be told anything other than “your booking reference has changed”, the swap is probably not like for like.

How Tripgic’s Hotel API Handles Repricing

Tripgic is a unified travel API, not booking software, that aggregates 2M+ hotel properties from 50+ suppliers. It runs hotel repricing on its standard Hotel API, not as a separate product: according to its repricing page, repricing is a scheduled job on top of the hotel calls a booking flow already uses. For a buyer, that means:

  • One integration for booking and repricing. The same search, rooms, price-check, create, voucher and cancel calls serve both. There is no separate product to buy.
  • A wide pool to re-shop. The Hotel API covers 190+ countries, with availability and rates queried in real time from the underlying suppliers. A re-shop sees the property across that pool in one normalised response.
  • Terms and rate plans as data. Refundable, non-refundable, breakfast-included, member and advance-purchase plans for a room come back in the same response, each with structured cancellation rules, and searches can filter by rate plan type, such as refundable-only.
  • A fee model you can plan around. Hotels return the supplier net rate plus a flat markup per room night, never a percentage commission, so your minimum-saving threshold is easy to set. Figures are on the pricing page.
  • Your rules, your saving. You decide the buffer, the minimum saving and who keeps the difference.

The same API also covers flights from 700+ airline and LCC connections and other travel products, so a platform can add repricing without adding a supplier. To test the loop, request sandbox access; the sandbox is free, and live activation typically takes 3–5 business days.

Should You Build a Repricing Job or Use a Ready-Made Tool?

There are three ways to run hotel repricing. The right one depends on your team and where your hotel bookings come from.

Option What you get Best for
Build on a hotel API (e.g. Tripgic) Full control of rules, cadence and who keeps the saving; repricing uses the same calls as booking Platforms with developers that already book hotels through the API
Ready-made repricing tool Monitoring, matching and alerts out of the box, across the suppliers you connect Agencies and wholesalers without a development team, or with bookings spread across many suppliers
Manual re-checking No setup; an agent re-searches and rebooks by hand Very low volumes only; it does not scale

Building on the API suits a platform whose hotel bookings already flow through Tripgic. The repricing job is mostly scheduling and matching logic on calls your developers already know.

If your team needs a finished tool instead, Drop Catch, from Tripgic’s group, Innovate Solution, is one. According to its page, it monitors confirmed refundable hotel bookings around the clock across every hotel supplier you connect, flags a drop only when the hotel, room type, dates, occupancy and booking terms all match, and rebooks either after your manual approval or automatically under rules you define.

Manual re-checking works for a handful of bookings. Beyond that, the hours spent re-searching cost more than most savings.

Is Hotel Repricing the Same as a Best Price Guarantee?

No. Hotel repricing is often confused with two other things that also involve a lower hotel price, but the seller runs repricing automatically on every eligible booking, while the guest has to act in the other two.

Hotel repricing Best price guarantee Price-drop alert
Who acts The seller, automatically The guest, by making a claim The guest, by rebooking themselves
When Any time until the free-cancellation deadline A short window, set by the hotel Whenever the guest notices
Scope Every eligible refundable booking Bookings where the guest finds and proves a lower price Hotels the guest chose to track
Who keeps the saving The seller decides The guest The guest

A best price guarantee is the hotel’s promise, not the seller’s process. Accor’s Best Price Guarantee, for example, matches a lower price found elsewhere within a set window after booking, once the guest submits a claim with proof.

A price-drop alert is a consumer feature: the guest gets an email and does the rebooking themselves. Repricing is the B2B version of the same idea. The seller watches every booking, runs the match, and acts under its own rules, which is why it needs an API rather than a browser.

Which Hotel Repricing Metrics Should You Track?

Measure hotel repricing as a product, not as a feature you switch on and forget. There is no single industry figure for how often a refundable booking gets cheaper, so your own numbers are the business case. Track these each week:

Metric What it tells you
Eligible bookings checked How many refundable bookings were inside the window and re-shopped
Opportunity rate The share of eligible bookings where a matching cheaper rate appeared
Rebooking success rate The share of attempts that completed both the new booking and the cancellation
Net saving, total and per rebooking The real result, and whether your minimum-saving threshold is set right
False matches and traveller incidents Rebookings later found to differ, and complaints or check-in problems linked to a swap
Search traffic used Re-shop searches as a share of your look-to-book allowance

False matches and traveller incidents deserve a target of zero. If either rises, tighten the matching rules or widen the safety buffer before you chase more savings. Net saving is the number to report to management, because the gross price gap overstates the result.

Hotel Repricing Launch Checklist

Use this list before switching repricing on for live bookings:

  1. Data. Every booking record stores the rate plan, board, occupancy, room mapping ID, free-cancellation deadline in UTC and the supplier reference.
  2. Matching. Room mapping is in place, and the matcher rejects any offer that differs on room, bed, board, occupancy, dates or terms.
  3. Order. The job books and confirms the new rate before cancelling the original, every time.
  4. Buffer. A safety buffer stops the job well before each deadline.
  5. Threshold. The minimum saving sits above the per-night fee on the new booking plus payment costs.
  6. Cadence. Re-check frequency fits your look-to-book allowance and rises near the deadline.
  7. Failure handling. If the cancellation fails, the job retries and alerts support before the deadline; if the booking fails, the original stays untouched.
  8. Traveller. New confirmations go out at once, special requests are copied, and terms explain the practice.
  9. Logging. Every attempt is logged with both prices, both cancellation terms and the result.
  10. Pilot. Run in “alert only” mode first: the job finds opportunities and a person approves each one, until false matches stay at zero. This is also where you measure your real opportunity rate.

Test the whole loop in a sandbox before going live. On Tripgic, the sandbox is free, so a test booking, re-shop, rebook and cancel can run before the job touches a live reservation. Our hotel API integration guide covers the base booking flow, and hotel API providers compares the market if you are still choosing a supplier.

Is Hotel Repricing Worth Building?

Hotel repricing is worth building when you hold enough refundable bookings with days or weeks of lead time, because it turns the free-cancellation window into margin or traveller savings. The mechanics are simple; the discipline is in the details covered above, and the alert-only pilot tells you whether the opportunity rate in your markets justifies switching on automatic rebooking.

For a platform already booking hotels through an API, repricing is not a new integration. It is a scheduled job on calls you already use. Tripgic’s Hotel API supports that loop across 2M+ properties, with structured cancellation terms and a flat per-night fee model. To see it working on your own bookings, book a demo.