# Booking.com Rate Calendar & Booking Curve (`apt_marble/booking-rate-calendar-scanner`) Actor

Build a price-by-date matrix for any Booking.com market: nightly rate, taxes, refundability and rank versus the market median for every property on every check-in date, plus per-date medians, quartiles and supply movement. Weekend premiums and the forward booking curve included.

- **URL**: https://apify.com/apt\_marble/booking-rate-calendar-scanner.md
- **Developed by:** [Hamza](https://apify.com/apt_marble) (community)
- **Categories:** Travel, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.40 / 1,000 rate row saveds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Booking.com Rate Calendar & Booking Curve

Turn any Booking.com market into a price-by-date matrix. Name a city — or a
`lat,lon` point — pick a first check-in date and how far ahead to look, and every
check-in date is measured separately: one row per property per date with its
nightly rate, taxes and fees, total, refundability, board basis, the room that was
matched, and where that price sits against the market median for that exact date.
On top of that you get one market row per date with the median, the quartiles, the
cheapest rate, the share of refundable offers and how supply moved against the day
before — and, once the sweep finishes, a forward curve per property: date-over-date
movement, weekend premium, minimum, maximum, median and rate volatility. It is
built for revenue managers, short-let operators, travel analysts and anyone who
needs to know what a market is charging on a given night. No Booking.com account,
no login, no personal details — just run it.

### What you can do with it

- **Read the forward booking curve.** Scan the next 90 check-in dates for your
  city and see exactly where the market firms up, where it discounts, and how far
  out prices start to climb.
- **Rate-shop a comp set.** Pin your competitors' property ids and get their
  nightly price on every date alongside your own, each one ranked and indexed
  against that date's market median.
- **Quantify the weekend premium.** Fri/Sat versus Mon–Thu, per property and per
  market, computed for you instead of eyeballed off a chart.
- **Spot compression before it shows up in your rates.** The market row tracks how
  much supply is on sale for each date, so the nights where inventory tightens
  stand out days or weeks ahead.
- **Price events and shoulder seasons.** Pass an explicit list of check-in dates —
  festival weekends, the first of each month, a race weekend — and skip everything
  in between.
- **Feed a dashboard or a warehouse.** Run it on a schedule; every row carries its
  check-in date, weekday, lead time and collection time, so a series appends
  cleanly and never needs a date guessed after the fact.

### What you get

Two kinds of row, told apart by `recordType`. A property on a date:

```json
{
  "recordType": "propertyDate",
  "hotelId": 1344239,
  "hotelName": "Austin Motor Inn",
  "hotelUrl": "https://www.booking.com/hotel/us/austin-motor-inn.en-us.html",
  "city": "Austin",
  "countryCode": "us",
  "latitude": 30.32271,
  "longitude": -97.70762,
  "starRating": 2,
  "reviewScore": 6.4,
  "reviewsCount": 1284,
  "checkIn": "2026-09-10",
  "checkOut": "2026-09-11",
  "nights": 1,
  "leadTimeDays": 42,
  "dayOfWeek": "Thu",
  "grossAmount": 41.99,
  "pricePerNight": 41.99,
  "taxesAndCharges": 7.64,
  "totalWithTaxes": 49.63,
  "currency": "USD",
  "originalAmount": null,
  "discountPercent": null,
  "freeCancellationUntil": "2026-09-09T05:00:00Z",
  "isRefundable": true,
  "mealPlanType": null,
  "mealPlanText": null,
  "scarcityMessage": null,
  "roomsMatched": "Double Room",
  "bedrooms": 1,
  "beds": 2,
  "bathrooms": 1,
  "priceIndexVsMarketMedianOnDate": 84.3,
  "priceRankOnDate": 1,
  "pricedPropertiesOnDate": 100,
  "dateOverDateDeltaPct": null,
  "weekendPremiumPct": 4.8,
  "minRate": 41.99,
  "maxRate": 43.99,
  "medianRate": 43.99,
  "rateVolatilityPct": 2.2,
  "datesObserved": 3,
  "datesMissing": 0,
  "isAvailable": null,
  "availabilityInferenceUnavailable": true,
  "notFoundOnDate": false,
  "pricingUnavailable": false,
  "destination": "Austin",
  "destinationType": "CITY",
  "scrapedAt": "2026-09-10T08:14:02.108Z"
}
```

And one market row per date:

```json
{
  "recordType": "marketDate",
  "destination": "Austin",
  "destinationType": "CITY",
  "checkIn": "2026-09-11",
  "checkOut": "2026-09-12",
  "nights": 1,
  "leadTimeDays": 43,
  "dayOfWeek": "Fri",
  "propertiesReturned": 100,
  "uniqueProperties": 100,
  "pricedProperties": 98,
  "pagesFetched": 1,
  "pagedToCompletion": false,
  "reportedMarketTotal": 298,
  "medianRate": 128.5,
  "p25Rate": 74.25,
  "p75Rate": 196.4,
  "minRate": 42.99,
  "maxRate": 612,
  "currency": "USD",
  "refundableShare": 0.75,
  "supplyChangeVsPreviousDatePct": -30.9,
  "scrapedAt": "2026-09-10T08:14:04.220Z"
}
```

That `-30.9` is the real thing this actor is for: a live Austin sweep showed the
number of properties on sale falling from 431 on the Thursday to 298 on the Friday
to 268 on the Saturday, while the cheapest rooms rose. The market row makes that
visible per date; the property rows tell you which properties did the moving.

### Input reference

The fields below are the ones you fill in on the actor's input form.

| Field | Type | Default | What it does |
| --- | --- | --- | --- |
| Destinations | list of strings | `["Austin"]` | Markets to measure. Place names (`Austin`, `Lisbon`) or coordinate pairs (`30.2672,-97.7431`). Up to 20 per run. |
| Destination type | select | `CITY` | How to read your place names: city, region, country, district, airport, landmark or coordinates. A coordinate pair is always read as coordinates. |
| First check-in date | date | empty | First check-in date to measure. Left empty, it starts seven days after the run begins, so a schedule keeps rolling forward. |
| Number of check-in dates | integer | `30` | How many consecutive check-in dates to measure, up to 90. |
| Specific check-in dates | list of strings | empty | An explicit list of dates (`2026-10-31`). When filled in, it replaces the first date and the horizon. Up to 90. |
| Lengths of stay (nights) | list of integers | `[1]` | Stay lengths to price, 1–14 nights, up to four of them. One night gives the cleanest nightly curve. |
| Only these check-in weekdays | list of strings | empty | Keep only these weekdays (`Fri`, `Sat`). Narrowing a 90-date scan to Fri/Sat leaves 26 dates and finishes far sooner. |
| Adults / Rooms / Children | integer | `2` / `1` / `0` | The party every rate is priced for. Keep it fixed between runs or the series is not comparable. |
| Children's ages | list of integers | empty | One age per child, 0–17. Booking.com prices children by age, so fill these in when children travel. |
| Result order | select | `price` (cheapest first) | Which slice of each market is measured. Cheapest first is pinned by default, because identical ordering on every date is what makes the curve comparable. |
| Properties per date | integer | `100` | How many properties to collect for each check-in date, up to 1,000. |
| Read each market to completion | boolean | `false` | Reads as much of the market as Booking.com will show for every date. This is what makes "sold out on this date" a sound answer instead of a guess, and it makes a run considerably longer. |
| Pinned property ids | list of integers | empty | Track a fixed comp set. Only these properties are saved, picked out of each market's results, and a date where one of them does not appear is saved with `notFoundOnDate` set. Up to 200. |
| Add a market row per date | boolean | `true` | Adds the per-date market summary shown above. |
| Add forward-curve metrics | boolean | `true` | Adds the per-property curve figures: date-over-date change, weekend premium, minimum, maximum, median, volatility, dates observed and missing. |
| Maximum work per run | integer | `400` | A hard ceiling on how much scanning one run may do. The size of the job is worked out before anything starts, and a run that would exceed the ceiling stops immediately and names the setting to lower. |
| Dates at a time | integer | `4` | How many check-in dates are measured simultaneously. Higher is quicker but more likely to be throttled by Booking.com. |
| Currency | string | `USD` | Three-letter code every rate is reported in. Pinned for the whole run. |
| Language | string | `en-us` | Language for names and labels. Non-English languages are untested. |
| Country to appear to browse from | string | `us` | Two-letter country code for the market view to use. Rates can differ slightly by country, so keep it fixed between runs. |

### Output fields

#### Property-date rows (`recordType: "propertyDate"`)

| Field | Type | Description |
| --- | --- | --- |
| `hotelId` / `hotelName` / `slug` | number / string | Booking.com's property id, its display name and its URL slug. |
| `hotelUrl` | link | Convenience link to the property page, derived from its slug and country. |
| `city` / `countryCode` / `latitude` / `longitude` | string / number | Where the property is. |
| `neighbourhood` / `distanceText` | string | Displayed area and distance from the search centre. |
| `starRating` / `reviewScore` / `reviewsCount` / `reviewScoreWord` | number / string | Star class, guest score, number of guest scores and Booking.com's word for the score. |
| `accommodationTypeId` / `isNewlyOpened` | number / boolean | Property type code and whether it is newly opened. |
| `checkIn` / `checkOut` / `nights` / `leadTimeDays` / `dayOfWeek` | date / number / string | The stay this price belongs to, and how far ahead of the run it is. |
| `adults` / `children` / `rooms` | number | The party the price was quoted for. |
| `grossAmount` / `pricePerNight` | number | Price for the whole stay, and per night — the figure that is comparable across dates and stay lengths. |
| `taxesAndCharges` / `totalWithTaxes` / `includesTaxes` | number / boolean | Charges shown as excluded from the headline price, the resulting total, and whether the headline price already includes them. |
| `currency` | string | The currency you pinned. |
| `originalAmount` / `discountPercent` | number | Only filled in when the pre-discount price is genuinely higher than the price charged. |
| `priceSource` | string | Whether the figure came from the property's stay price or from its cheapest matching offer. |
| `pricingUnavailable` | boolean | True when no price could be read for the property on this date. The amounts are then blank — never zero. |
| `freeCancellationUntil` / `isRefundable` | date / boolean | Free-cancellation deadline for the matched offer. A blank deadline means the offer is non-refundable. |
| `mealPlanType` / `mealPlanText` | string | Board basis included in the price. |
| `scarcityMessage` / `scarcityTag` | string | "Only 2 left" style badge when Booking.com shows one. Rare. |
| `roomsMatched` / `roomTypes` / `bedrooms` / `beds` / `bathrooms` | string / number | The room configuration that was priced for your party. |
| `priceIndexVsMarketMedianOnDate` | number | 100 means exactly the market median for that date; 84.3 means 15.7% below it. |
| `priceRankOnDate` / `pricedPropertiesOnDate` | number | Where this price sat among the properties measured for that date, cheapest first. |
| `dateOverDateDeltaPct` | number | Change against the previous date on which this property was actually priced. |
| `weekendPremiumPct` | number | Fri/Sat mean against Mon–Thu mean for this property over the whole scan. |
| `minRate` / `maxRate` / `medianRate` / `rateVolatilityPct` | number | This property's own curve across every date scanned. |
| `datesObserved` / `datesMissing` | number | How many of the dates you asked for actually produced a price for this property. |
| `isAvailable` / `availabilityInferenceUnavailable` | boolean | Availability is only stated when the whole market was read for the date; otherwise it is blank and the second flag says so. |
| `notFoundOnDate` | boolean | True on a pinned property that did not appear in that date's results. |
| `destination` / `destinationType` / `position` | string / number | Which input produced the row and where it sat in that date's results. |
| `actorRunId` / `scrapedAt` | string / date | Run identifier and collection time. |

#### Market-date rows (`recordType: "marketDate"`)

| Field | Type | Description |
| --- | --- | --- |
| `destination` / `destinationType` | string | The market this row describes. |
| `checkIn` / `checkOut` / `nights` / `leadTimeDays` / `dayOfWeek` | date / number / string | The date this row describes. |
| `propertiesReturned` / `uniqueProperties` / `pricedProperties` | number | Rows seen, distinct properties among them, and how many carried a readable price. |
| `pagesFetched` / `pagedToCompletion` | number / boolean | How much of the market was read for this date, and whether it was read out fully. |
| `reportedMarketTotal` | number | The total Booking.com itself displayed for this search. A snapshot, not an audited figure. |
| `medianRate` / `p25Rate` / `p75Rate` / `minRate` / `maxRate` | number | Per-night rate distribution for the date. |
| `currency` | string | The currency you pinned. |
| `refundableShare` | number | Share of measured properties whose matched offer can be cancelled free. |
| `supplyChangeVsPreviousDatePct` | number | Movement in the displayed market total against the previous date for the same stay length. |
| `actorRunId` / `scrapedAt` | string / date | Run identifier and collection time. |

### Pricing

This actor is **pay per event**, with two charges.

- **Rate row saved — $0.0004 each, $0.40 per 1,000 rows.** The built-in
  per-result charge. It fires once for every row written to the dataset, whether
  that is a property on a date or a market summary for a date.
- **Date scanned — $0.003 each.** A charge applies each time one check-in date in
  one market is actually measured and its market-level summary is produced. This
  is the honest cost driver: Booking.com publishes no price calendar, so every
  check-in date has to be measured on its own, and a date costs the same work
  whether it comes back with a hundred properties or three.

A typical run — one market, 30 check-in dates, 100 properties per date — produces
3,000 property rows plus 30 date summaries and costs about **$1.29**. A 90-date
year-ahead curve on a 25-property comp set costs about **$1.21**. Turning off the
market row leaves only the per-row charge, so a pure rate feed is $0.40 per
thousand rows flat.

If you set a maximum cost for a run, the actor stops cleanly as soon as that
budget is spent rather than overshooting it, and it will not begin measuring a
date it cannot bill for.

### Limits & what this actor cannot do

- **There is no Booking.com price calendar.** Every check-in date is measured
  separately. That is why the horizon is capped at 90 dates, why each extra date
  and each extra length of stay makes a run longer, and why the size of the job is
  worked out and reported before anything starts.
- **Booking.com shows at most about 1,000 properties for any one search.** For a
  large market that is the ceiling per date, and past it Booking.com begins
  repeating properties it has already shown. Every date is de-duplicated, and a
  date stops as soon as it stops producing new properties.
- **Booking.com's own market total moves between identical searches** — a few
  units apart within minutes. `reportedMarketTotal` is a snapshot for comparing
  one date against another, not an audited count.
- **"Sold out" is only reported when the whole market was read.** A property that
  is missing from a date's results has usually just fallen out of the slice you
  asked for — in a live test, 12 distinct properties turned up across three
  consecutive dates and only 5 appeared on all three, almost entirely because the
  cheapest-first ordering shows a different set each day. Unless you switch on
  "Read each market to completion", availability is left blank and the row says
  so explicitly, rather than guessing.
- **A named hotel cannot be priced on its own.** Rates are only published inside a
  market's results, so a property is tracked by pinning its id and picking it out
  of the market. If it has no availability on a date it will simply be absent, and
  that date is saved with `notFoundOnDate` set.
- **Booking.com shows one to two offers per property for your dates, not a full
  room list.** Each row is that property's cheapest matching offer for your party,
  with its cancellation terms — not its room inventory.
- **Prices are pinned to the currency you choose**, and rates can differ slightly
  by the country the run appears to browse from. Keep both fixed between runs or a
  series is not comparable.
- **Discounts are only reported when the pre-discount price genuinely differs.**
  On live samples the two were equal on every property, so a 0% discount is never
  reported as a finding.
- **Scarcity badges appear rarely.** Treat them as a bonus signal, not a
  guarantee.
- **A property with no readable price is saved with `pricingUnavailable` set and
  blank amounts, never a zero** — a zero would read as a free room and would
  distort every median and index in the dataset.
- **Speed depends on the size of the job** and on Booking.com's own response
  times. No fixed throughput is promised.
- **Booking.com's terms prohibit automated access.** You are responsible for using
  the data lawfully and in line with the source site's terms.

### FAQ

**Do I need a Booking.com account?**
No. No account, no login, no personal details — enter a market and some dates and
run it.

**How far ahead can it look?**
Up to 90 check-in dates in one run, starting from any future date. For a longer
horizon, run it more than once with different start dates and merge the results —
each row carries its own check-in date, so a merge is trivial.

**Can I run it on a schedule?**
Yes, and that is the intended use. Leave the first check-in date empty and it
always starts seven days after the run begins, so a daily or weekly run keeps
rolling forward on its own instead of drifting into the past. Keep the party size,
the currency, the ordering and the country fixed and every run appends cleanly to
the same series.

**How do I track my own hotel and its competitors?**
Put their property ids in "Pinned property ids". Only those properties are saved,
but each one is still ranked and indexed against the full market for that date, so
you get both the comp set and its context. A pinned property missing from a date
is saved with `notFoundOnDate` set, so gaps in the curve are visible rather than
silent.

**Is the data complete?**
For the dates and the depth you asked for, yes — but read the limits above. The
big one: Booking.com will not show more than about 1,000 properties for a single
search, and a property's absence from a date is not proof it sold out unless you
switched on "Read each market to completion".

**Why is there a market row as well as property rows?**
Because the market moves even when individual properties do not. The market row
gives you the median, the quartiles and the change in how much supply is on sale
for each date, which is what tells you a date is tightening before any single
property's price has moved.

**What happens if one of my destinations cannot be found?**
It is reported in the run log and skipped, and every other destination on your
list still runs.

# Actor input Schema

## `destinations` (type: `array`):

Markets to scan. Type place names (Austin, Lisbon, Bali) or coordinate pairs (30.2672,-97.7431). Each destination is scanned across every check-in date you choose.

## `destinationType` (type: `string`):

How to read your place names. City covers most needs; use Region for a state or province, District for a neighbourhood, and Coordinates when you pass lat,lon pairs. Coordinate pairs are always read as coordinates whatever you pick here.

## `startDate` (type: `string`):

First check-in date of the scan, as YYYY-MM-DD. Leave empty to start seven days from the day the run begins, which keeps scheduled runs rolling forward instead of drifting into the past.

## `horizonDays` (type: `integer`):

How many consecutive check-in dates to scan, starting from the first check-in date. Each date is checked on its own, so this is the main thing that drives how long a run takes.

## `checkInDates` (type: `array`):

An explicit list of check-in dates as YYYY-MM-DD. When this is filled in it replaces the first check-in date and the horizon, which is handy for scanning only event weekends or the first of each month.

## `lengthsOfStay` (type: `array`):

Stay lengths to price, in nights. Every extra length multiplies the whole scan, so up to four are allowed, each between 1 and 14 nights. A one-night stay gives the cleanest nightly curve.

## `daysOfWeek` (type: `array`):

Keep only check-in dates that fall on these weekdays (Mon, Tue, Wed, Thu, Fri, Sat, Sun). Leave empty for every day. Narrowing to Fri and Sat cuts a 90-date scan to 26 dates.

## `adults` (type: `integer`):

Adults the rates are priced for. Party size changes which properties and rates qualify, so keep it fixed across scheduled runs.

## `rooms` (type: `integer`):

Rooms to price for the party.

## `children` (type: `integer`):

Children travelling with the party. Add their ages below for accurate rates — Booking.com prices children by age.

## `childrenAges` (type: `array`):

One age per child, 0 to 17. When these are filled in they set the number of children too.

## `sortBy` (type: `string`):

Which slice of the market each date returns. Cheapest first is the default and is pinned deliberately: the same ordering on every date is what makes the curve comparable.

## `maxPropertiesPerDate` (type: `integer`):

How many properties to collect for each check-in date. Anything above 100 reads several slices of the market for that date.

## `pageToCompletion` (type: `boolean`):

Read as much of the market as Booking.com will show for every date. This is what makes "this property is sold out on this date" a sound answer instead of a guess — without it, a property missing from a date is simply not reported for that date. It also makes a run considerably longer.

## `pinnedHotelIds` (type: `array`):

Track a fixed comp set. Only these properties are saved, picked out of each market's results, and a date where one of them does not appear is saved with notFoundOnDate set so gaps in the curve are visible.

## `emitMarketRow` (type: `boolean`):

Adds one row per market per date with the median, the quartiles, the cheapest rate, the share of refundable offers and how supply moved against the previous date. Costs no extra work.

## `deriveCurveMetrics` (type: `boolean`):

Adds per-property curve figures once the scan finishes: date-over-date change, weekend premium, minimum, maximum and median rate, rate volatility, and how many dates were observed or missing.

## `maxRequests` (type: `integer`):

A hard ceiling on how much scanning a single run may do. The projected amount is worked out and logged before anything starts, and a run that would exceed this stops immediately and names the setting to lower.

## `maxConcurrency` (type: `integer`):

How many check-in dates are worked on simultaneously. Three is the balance point: higher is faster but more dates get turned away, and the run eases off automatically when that starts happening. Any date that is turned away is retried once before it is reported as missing.

## `currency` (type: `string`):

Three-letter currency code every rate is reported in. It is pinned for the whole run, because a series priced in a shifting currency is meaningless.

## `language` (type: `string`):

Language for names and labels, such as en-us, en-gb, de or fr. Non-English languages are untested.

## `proxyCountry` (type: `string`):

Two-letter country code for the market view the run should use, for example us, gb or de. Rates can differ slightly by country, so keep it fixed between runs.

## Actor input object example

```json
{
  "destinations": [
    "Austin",
    "Lisbon"
  ],
  "destinationType": "CITY",
  "startDate": "",
  "horizonDays": 30,
  "checkInDates": [
    "2026-09-11",
    "2026-09-12",
    "2026-10-31"
  ],
  "lengthsOfStay": [
    "1",
    "3",
    "7"
  ],
  "daysOfWeek": [
    "Fri",
    "Sat"
  ],
  "adults": 2,
  "rooms": 1,
  "children": 0,
  "childrenAges": [
    "7",
    "11"
  ],
  "sortBy": "price",
  "maxPropertiesPerDate": 100,
  "pageToCompletion": false,
  "pinnedHotelIds": [
    "1344239",
    "517530"
  ],
  "emitMarketRow": true,
  "deriveCurveMetrics": true,
  "maxRequests": 400,
  "maxConcurrency": 3,
  "currency": "EUR",
  "language": "en-us",
  "proxyCountry": "us"
}
```

# Actor output Schema

## `dataset` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "destinations": [
        "Austin"
    ],
    "destinationType": "CITY",
    "horizonDays": 30,
    "lengthsOfStay": [
        "1"
    ],
    "adults": 2,
    "rooms": 1,
    "sortBy": "price",
    "maxPropertiesPerDate": 100,
    "maxRequests": 400,
    "maxConcurrency": 3,
    "currency": "USD",
    "language": "en-us",
    "proxyCountry": "us"
};

// Run the Actor and wait for it to finish
const run = await client.actor("apt_marble/booking-rate-calendar-scanner").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "destinations": ["Austin"],
    "destinationType": "CITY",
    "horizonDays": 30,
    "lengthsOfStay": ["1"],
    "adults": 2,
    "rooms": 1,
    "sortBy": "price",
    "maxPropertiesPerDate": 100,
    "maxRequests": 400,
    "maxConcurrency": 3,
    "currency": "USD",
    "language": "en-us",
    "proxyCountry": "us",
}

# Run the Actor and wait for it to finish
run = client.actor("apt_marble/booking-rate-calendar-scanner").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "destinations": [
    "Austin"
  ],
  "destinationType": "CITY",
  "horizonDays": 30,
  "lengthsOfStay": [
    "1"
  ],
  "adults": 2,
  "rooms": 1,
  "sortBy": "price",
  "maxPropertiesPerDate": 100,
  "maxRequests": 400,
  "maxConcurrency": 3,
  "currency": "USD",
  "language": "en-us",
  "proxyCountry": "us"
}' |
apify call apt_marble/booking-rate-calendar-scanner --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,apt_marble/booking-rate-calendar-scanner"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/1GndYC5uQEoh44ivW/builds/hOK2EktImfTsP9nUF/openapi.json