Mode to charge event for all ten Booking.com scraper modes, what one unit is, and which events are not priced yet. No figures - the Pricing tab is generated.
Describes build 1.0.173 of rl1987/booking-api-scraper, deployed 2026-10-29. The column set last changed 2026-10-29. Earlier builds can return a different one.
Charging happens on delivery, not on request: a surface that fails or comes back empty is free. Every surface costing a separate API request is its own event, so you pay for what you asked for and nothing else.
No prices here on purpose - they are plan-tiered and generated, so read them on the Actor’s Pricing tab. This page says which events a mode fires and what one unit is.
| mode | events it fires | plus, if you switch them on |
|---|---|---|
search | search-result | includeRooms, includeDetails, includeReviews, includeReviewScores, includeSurroundings |
rooms | room-details | includeDetails, includeReviews, includeReviewScores, includeSurroundings |
rates | rate-check or room-details - see below | - |
reviews | review, review-scores | - |
reviewScores | review-scores | - |
surroundings | surroundings | - |
details | hotel-details | - |
attractions | attraction-row | - |
attractionDetails | attraction-detail | - |
attractionAvailability | attraction-availability | - |
| event | charged per | covers | priced |
|---|---|---|---|
search-result | accommodation returned | the property result with live pricing | live |
hotel-details | property | two requests - property page + static content - deliberately billed as one | live |
room-details | room option returned | the per-rate products list comes from the same request and is not charged again | live |
review | review returned | the paginated review list | live |
surroundings | property | one request per property | live |
review-scores | property | one request regardless of review count | live |
rate-check | product id checked | including rates that have sold out, which cost the same request | from 2026-11-08 |
attraction-row | attraction returned | the catalogue row with its price | from 2026-11-08 |
attraction-detail | attraction | the full product record | from 2026-11-08 |
attraction-availability | attraction, across the date window asked for | one row per attraction, not per date | from 2026-11-08 |
The four events marked with a date are charged by the code today and priced in no live entry, so those rows deliver unbilled until it starts. The same run, unchanged and with no new build, is billed differently on either side of that date - which is the one thing to know before reconciling invoices across it.
| toggle | adds the event | per |
|---|---|---|
includeRooms | room-details | room option returned |
includeDetails | hotel-details | property |
includeReviews | review | review returned |
includeReviewScores | review-scores | property |
includeSurroundings | surroundings | property |
One property, one stay, per enrichment mode. Requests are proxied calls - they count toward platform usage, not toward a per-item event - so the two columns deliberately disagree: you are charged per unit DELIVERED, not per request made.
| mode | requests made | events charged |
|---|---|---|
rooms | 3 | room-details=5 |
reviews | 3 (2 if you pass ufi) | review=3, review-scores=1 |
reviewScores | 1 | review-scores=1 |
surroundings | 1 | surroundings=1 |
details | 2 | hotel-details=1 |
search-result=0 in all five: an enrichment row carries one surface and no property summary, so there is no search result to bill. Re-measured 2026-10-22, when rooms and details each gained the cot-and-extra-bed lookup and rooms also started paying the one-field slug query behind its url - the charges did not move, because those are requests and not events.
rates - No unconditional event. _resolve_rate_event reads the live pricing each run and charges rate-check where it is priced, room-details where it is not. Today that means room-details; from 2026-11-08 it means rate-check, with no new build.
reviews - Also bills review-scores, one per property, whether or not you asked for it: include_review_scores = enrich_mode in ("reviewScores", "reviews") in src/main.py. It is a separate request, so it is a separate charge - but the README said it was includeReviewScores only, which was wrong. Measured 2026-10-28: a 5-review run on one property charged review=5 and review-scores=1.
attractions - Delivers unbilled until 2026-11-08: attraction-row is charged in code but priced in no live entry. Measured 2026-10-28: a 100-row run charged nothing.
Apify Toolkits