Google Hotels API

# Integrate HasData Google Hotels API

## Task

Add the requested hotel-search or property-data workflow to this project using HasData Google Hotels 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 requested workflow. If it is unclear, ask whether the user needs destination searches, a specific property's details, or both.
Do not replace the REST integration with an MCP connection or a custom Google Hotels scraper.

## References

Read the endpoint documentation before implementing:

- Hotel search, property details, parameters, and response: https://docs.hasdata.com/apis/google-travel/hotels.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 reference. 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

- Use `GET https://api.hasdata.com/scrape/google/hotels` with required `q`, `checkInDate`, and `checkOutDate`.
- Accept a destination or hotel query and future `YYYY-MM-DD` dates, with checkout after check-in. Do not hardcode the documentation's sample dates.
- Keep `currency`, `adults`, `children`, and `childrenAges` explicit when the workflow requires them. Validate guest counts and one documented age per child against current docs. Do not silently choose dates or guest counts for the user.
- Add only the filters the task needs. Use the documented names and serialization, including `amenity[]` and `propertyType[]` if applicable. Hotel and vacation-rental filter values use different catalogs; do not mix them.
- Encode query parameters correctly. Preserve `properties`, `ads`, and `pagination` separately when present. Do not merge sponsored properties into organic search results without a label.
- For a requested property-details workflow, reuse the returned `propertyToken` with the same endpoint and applicable search context. Read the documented detail response shape; do not assume it is identical to the search list.
- If pagination is needed, expose `nextPageToken` from the response. Do not automatically fetch every page or every property detail.
- Preserve nightly prices separately from full-stay totals, including before-tax values and selected currency. Do not multiply rounded nightly prices to replace returned totals.
- Keep hotel star class separate from guest rating. Missing amenities or review topics are unknown, not verified absences. Review-topic counts are mentions, not percentages of all guests.
- Save query, dates, currency, guest context, and observation time alongside data used for comparisons. Search prices are observations, not reservations or guaranteed availability.
- Handle timeouts, documented errors, empty results, and missing optional fields. Keep requests server-side. If no suitable runtime exists, 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, hotel links, or redirects to another origin.

## Verification

- Add mocked tests for dates and guest validation, query encoding, success, empty results, missing fields, and errors. Cover tax/total distinctions and the chosen search or detail response shape. 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. A successful Google Hotels request consumes 10 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.