Integer ID reference

Every numeric vocabulary this Actor maps to a name, how complete each map is, and how we know.

Booking publishes none of these. Three of the tables below were lifted whole from the Booking Android app and are closed - a gap in them means no such id. The rest were learned by observing live payloads, and there a missing id means we have not seen it, not no such type exists. Each table says which it is. An unmapped id is always passed through with its raw number rather than dropped, so no row loses information to a gap.

Accommodation types

Where it appears: accommodationTypeId on a property row, and the accommodationTypes input. Booking’s own search filters use the same ids as property_type::<id>.

Coverage: 24 ids, from 201 to 228. 4 ids inside that range are unmapped, and ids outside it may exist too, so treat the table as partial.

Provenance: Learned from live payloads: every name is the accommodationTypeName Booking itself returned beside the id, across 15 destinations. The vocabulary does not stop at 228 - the app’s Hotel$HotelType enum references 229, 230 and 232, which we have never been served. That enum is a coarse seven-way roll-up, so it cannot supply a name for them; the real id -> name list is served by Booking’s filter API, localised.

Room types

Where it appears: products[].roomTypeId. Resolved to roomTypeCode on the row.

Coverage: 20 ids, from 1 to 33 - the complete vocabulary. The 13 ids missing inside that range are not defined upstream either.

Provenance: The complete BlockType enum, lifted from the APK and re-read independently by a second job. The 13 gaps are ids the enum itself does not define. UNKNOWN (20) is the app’s own fallback rather than a room category.

Bed types

Where it appears: rooms[].beds[].typeId, beside the localised beds[].name.

Coverage: 8 ids, from 1 to 8 - the complete vocabulary. No gaps.

Provenance: Closed at 8: the app’s icon dispatch is a jump table over exactly 1-8, so it knows of no ninth id. The codes here are ours; the app carries no label per id, only an icon, so the human string is always Booking’s own name - which is sometimes absent, making the id the only reliable key.

Charge and tax types

Where it appears: price.extra_charges.details[].chargeTypeId. The search path sends the id with no localised name, so an unmapped id is passed through as TYPE_<n> with the raw number kept - identifiable, just not named.

Coverage: 7 ids, from 21 to 148. 121 ids inside that range are unmapped, and ids outside it may exist too, so treat the table as partial.

Provenance: The most incomplete table here, and it cannot be completed from the app. The numeric id is a server-side enum the app never names: a grep across all 24 dex files for these constants returns nothing, and the app’s own charge model is string-based. Each of these seven was earned by matching a search-path amount to the cent against a named rate-level line, and that is the only way to earn another. On the rate level you do not need this table - Booking sends the name.

Payment method types

Where it appears: acceptedPaymentMethods[].id - what the property takes at the property, which is not the same question as what you can pay with through Booking. The row already carries Booking’s own name and nameEn, so this table is for joining, not for labelling: the name is localised and moves with the request locale, the id does not.

Coverage: 72 ids, from 1 to 76 - the complete vocabulary. The 4 ids missing inside that range are not defined upstream either.

Provenance: The app’s complete credit_card_types_keys resource array, English default; 6, 20, 24 and 33 are genuinely absent. Booking’s field name is not a description of its contents - 18 Cash only, 45 Cash, 46 PayPal, 57 M-Pesa and 62 iDeal are not cards.