What one dataset row represents. Billing is per offer or per answered date, never per row — so the same data costs the same whichever shape you pick.
• 'One row per room rate' (default) — the full room-level result: every rate plan a property is selling for every date, with prices, taxes, cancellation terms and amenities. One page fetch per hotel-date. Rows per hotel-date vary by property: a single-room lodge yields one or two, a large hotel ~34.
• 'One row per date (availability calendar)' — Booking's own per-date availability and minimum stay across the whole window, plus one property record per hotel. Costs ONE page fetch per hotel plus one availability call per 61 days, and bills one result per date. On a large hotel that is roughly 34x fewer billed results than the default; on a single-room lodge, about the same. Carries no room detail and no real prices.
• 'One row per date, rooms nested' — the same room-level data as the default, grouped by date. Same fetches and the SAME bill as the default: a nested row bills one result per rate plan inside it. Only the JSON shape differs.
'Days ahead' multiplies results in every mode. 'discovery' returns only each property's profile - name, address, coordinates, star rating, review score, check-in windows and house rules including children's age bands - with no availability at all. It is the cheapest way to harvest property data: one request per property instead of two, no availability calendar call, and billed per property rather than per rate.
Options:offerscalendarcalendar_roomsdiscovery