BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Booking.com's search-card total leaves out $175.84 of a $1,296.79 New York Hyatt stay
Booking.com's priceTotal omitted 9-16% of the stay price across 24 search rows, including $175.84 on a New York Hyatt, a scraper author reported. Sheets sorted on that field understate cost until they add the excluded-charges field. Rates differ by city, so cross-city rankings tilt.
The Engineer · Build desk

Hyatt Regency Times Square card priceTotal: $1120.95. In New York, codes 21 and 23 add 14.75% of priceTotal, against 6% in Lisbon and 10% in Tokyo. A $500 New York stay really costs about $580; a $500 Tokyo stay about $550.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Hyatt NY search-card priceTotal | 1,120.95 USD | 4 | |
| NY code 21/23 charge rate | 14.75 % of priceTotal | Lisbon 6%, Tokyo 10% | 8 |
| $500 NY stay really costs | 580 USD, about | Tokyo $500 stay: about $550 | 12 |
What happened
- The operator ran one stay, 20 to 23 November 2026 for two adults in one room, against four destinations on 12 October 2026.
- According to the post, priceTotal is the figure Booking prints on the search card and sorts by, and nobody pays it.
- Code 22 was a flat per-stay amount identical across a city: EUR 24 in Lisbon, $10.50 in New York and $0 in Tokyo.
- Codes 21 and 23 were a percentage of priceTotal: 6% in Lisbon, 14.75% in New York and 10% in Tokyo.
- Adding the excluded charges flipped no pair of properties within a city across all 24 rows, the author reports.
Why it matters
- exposure A cheapest-city chart built on priceTotal moves with each city's charge rate. The post puts a $500 Tokyo stay at about $550 paid and a $500 New York stay at about $580.
- constraint The integer codes support a corrected total but not a breakdown by charge type. Nothing in the response names 21, 22 or 23, and the author declines to.
- decision Pipeline owners have to decide what an empty excluded-charges field means. The author's first mapper returned it empty on every row for a while, and the sample sort code falls back to zero.
The post's author, who runs a visa agency in Bali and builds scrapers on Apify, traces the integers to the response itself [1]. In Booking's GraphQL search response, each excluded charge comes back as an object with the fields chargeMode, chargeInclusion, chargeType and amountPerStay [5]. For an anonymous caller, chargeType is an integer [5]. No translation node sits beside it, as one does on badges, cancellation copy and review text [6]. The site itself shows "+ taxes and charges" and puts the breakdown in a tooltip assembled elsewhere [6].
Bali is where the codes matter most. Three properties left out 9.01%, the other three 10.99%, and the charge code matched the rate on every one of them [9]. The author ships the integers and will not label 22 as a city tax on six rows per market. He said: "An unexplained 22 makes you go look. A wrong CITYTAX does not." [10]
The 9-16% range in the post's headline is a share of priceTotal [16]. Measured that way, the Hyatt row sits at the top of it: $175.84 over $1120.95 is 15.7% [17]. Against the $1296.79 the guest pays, the same charges are 13.6% [18]. The author writes: "If your rate-shopping table says $1120.95, your table is wrong by the size of a whole night." [13] By the post's dates the stay is three nights, so a night on priceTotal is $373.65, and the omitted charges come to 0.47 of one [19].
Within a city, rankings survive when every property carries the same rate. Bali carries two. A property on the 10.99% code overtakes one on the 9.01% code whenever their priceTotals are within about 1.8% of each other, ignoring flat charges [20]. In our view six Bali rows are too few to rule out a pair that close.
Everything here comes from one operator's runs on one day: a single stay window, an anonymous caller, six rows per market [3][5]. The post does not report other dates or room counts, so 14.75% is what New York showed for that stay [8].
What to watch
- A repeat run on other dates and room counts, to see whether 14.75% in New York and 6% in Lisbon hold or belong to this one stay.
- Whether Booking adds a translation node beside chargeType so anonymous callers see names instead of 21, 22 and 23.
- A larger Bali sample, where two charge rates coexist and close-priced pairs could change order.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap+10
- Incentives35
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The post's author runs a visa agency in Bali and builds scrapers on Apify, one of which reads Booking.com search pages and returns one row per property.
- [2]
priceTotal is the number Booking prints in the search card and the number the site sorts by; the author says it is not the number anybody pays.
- [3]
On 12 October 2026 the author ran the same stay, 20 to 23 November 2026, two adults, one room, against four destinations and read all 24 rows.
- [4]
For the Hyatt Regency Times Square, priceTotal was $1120.95, the row carried $175.84 of charges that price does not contain, and the guest pays $1296.79.
- [5]
Booking's GraphQL search response returns excluded charges as a list of objects carrying chargeMode, chargeInclusion, chargeType and amountPerStay, and for an anonymous caller chargeType is an integer.
- [6]
There is no translation node next to chargeType, as there is on badges, cancellation copy and review text; the site renders '+ taxes and charges' and hides the breakdown behind a tooltip assembled elsewhere.
- [7]
Code 22 was always a flat amount per stay, identical across every property in a city: EUR 24 in Lisbon, $10.50 in New York, $0 in Tokyo and on three Bali rows.
- [8]
Codes 21 and 23 were always a percentage of priceTotal: 6% in Lisbon, 14.75% in New York, 10% in Tokyo, and in Bali 9.01% under code 21 and 10.99% under code 23.
- [9]
Within Bali, three properties excluded 9.01% and three excluded 10.99%, and which rate applied tracked exactly with the charge code in the field.
- [10]
The author ships the integers and will not guess that 22 means city tax on six rows per market. He said: "An unexplained 22 makes you go look. A wrong CITYTAX does not."
- [11]
The author checked all 24 rows and found that adding the excluded charges did not flip a single pair; Lisbon and New York stayed in the same order.
- [12]
Across cities a $500 Tokyo stay really costs about $550 and a $500 New York stay about $580, so a cheapest-city chart on priceTotal hands New York a 6% discount it does not get.
- [13]
The author wrote: "If your rate-shopping table says $1120.95, your table is wrong by the size of a whole night."
- [14]
The author's sample sort key is priceTotal plus (taxesAndFeesExcludedTotal or 0), so a missing field falls back to zero; he flags the 'or 0' just before describing a bug he found in his own code.
- [15]
The author's first mapper expected charge names, and the excluded-charges field was empty on every row for a while because he was reading a translation key that is not there.
- [16]
The post's headline puts the share of the price hidden in the excluded-charges field at 9-16%.
- [17]
The excluded $175.84 is about 15.7% of the Hyatt row's priceTotal.
- [18]
The excluded $175.84 is about 13.6% of the $1296.79 the guest pays.
- [19]
A three-night stay at $1120.95 priceTotal is $373.65 a night, and $175.84 is about 0.47 of a night.
- [20]
A Bali property charged 10.99% overtakes one charged 9.01% when its priceTotal is within about 1.8% of the other's, ignoring flat charges.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toBooking.com Search Rows Hide 9–16% of the Price in a Field Labelled 21, 22 and 23
1 article · October 11, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Web ScrapingFollow
- Hotel price transparencyFollow
- Travel data qualityFollow