Booking.com Scraper API

# Integrate HasData Booking.com Scraper API

## Task

Add the requested accommodation search or property-data workflow to this project using HasData Booking.com Scraper API.
Inspect project instructions, the server-side runtime, existing HTTP client, and tests first.
Follow the project's conventions and preserve unrelated code. No new SDK is required.
Implement only the endpoint or workflow needed for the user's task; do not add a full travel platform.
If the task is unclear, ask whether they need search results, property details, or both.
Do not replace the REST integration with an MCP connection or a custom Booking.com scraper.

## References

Read the endpoint documentation before implementing:

- Hotel search: https://docs.hasdata.com/apis/booking/search.md
- Property details and room offers: https://docs.hasdata.com/apis/booking/place.md
- Error handling: https://docs.hasdata.com/api-codes.md
- Documentation index: https://docs.hasdata.com/llms.txt
- Full documentation (fallback): https://docs.hasdata.com/llms-full.txt

Start with the endpoint references. Use `llms.txt` to find additional pages.
Use `llms-full.txt` only when needed; extract relevant sections instead of loading everything into context.
If a `.md` reference is unavailable, try its HTML URL without `.md`.
If it is still unavailable, ask for the missing documentation rather than guessing.

## Optional agent skill

If the official `hasdata` skill is already available, use its relevant guidance.
Otherwise, if this agent supports skills, ask before installing it in this project:

```sh
npx skills add hasdata/agent-skills --skill hasdata
```

Run from the project directory and select the coding agent in use.
The `hasdata-cli` skill is not required. If installation is declined or unsupported, continue with the docs.
Flag conflicts between skill guidance and current API docs rather than guessing.

## Implementation

- Search: `GET https://api.hasdata.com/scrape/booking/search`, with required destination `keyword`.
- Property details: `GET https://api.hasdata.com/scrape/booking/place`, with required `url` from `booking.com` or `www.booking.com`.
- Both endpoints require `checkInDate`, `checkOutDate`, `rooms`, `adults`, and `children`. Use future `YYYY-MM-DD` dates, with checkout after check-in; send `children=0` when there are none.
- If `children > 0`, include comma-separated `childrenAges`: one age from 0 to 17 per child. Validate counts before making a request.
- Accept documented `currency` and `language` options as needed. Use a fixed currency for comparisons and preserve dates, room counts, and guest counts with each result.
- Encode query parameters correctly. Preserve search `results` and `pagination`, or available property `overview`, `rooms`, `reviews`, and `houseRules` without flattening room variants.
- If search pagination is needed, expose `page`; do not automatically fetch every page or add every optional filter.
- Keep per-stay prices, excluded charges, room-variant totals, and cancellation conditions distinct. Do not treat different room types as equivalent offers or infer a reservation from search availability.
- Handle timeouts, documented errors, empty searches, and missing optional fields. Preserve guest scores separately from hotel star ratings.
- Keep requests server-side. If there is no suitable server-side runtime, discuss options before changing the architecture.

## Credentials

- Implement the integration and mocked tests without requiring a live API key.
- Read `HASDATA_API_KEY` from the project's existing environment or secret store and send it as `x-api-key`.
- If the key is missing before live verification, ask the user to configure it from https://app.hasdata.com/api-keys.
- Never ask the user to paste the key into chat. Check only that it is configured, without printing its value.
- Never put the key in browser code, logs, or version control. Add only a placeholder to the project's example configuration.
- If using a local `.env` file, make sure it is gitignored.
- Send the key only to `https://api.hasdata.com`. Never forward it to documentation, result URLs, or redirects to another origin.

## Verification

- Add mocked tests for dates and child-age validation, query encoding, success, empty searches, missing optional fields, and errors. Cover the room/price shape of the chosen endpoint. Include a usage example and run local checks.
- Only after explicit user approval and with a configured key, make one live verification request with agreed inputs and valid dates where required. Successful requests consume credits.
- Validate the HTTP status, documented API status, and response structure. An empty result set can be valid.
- Do not automatically repeat paid requests to obtain a nonempty response.
- Report changed files, setup commands, and test results. State separately whether live verification passed, failed, or was skipped.
- Ask before deploying.