Airbnb Stay Search Scraper
Pricing
$0.80 / 1,000 stay listings
Airbnb Stay Search Scraper
Find public stays by destination and dates. Get nightly and total prices, ratings, review counts and room details in a structured dataset.
Airbnb Stay Search Scraper — Dates, Prices & Accommodation Details
Search public accommodation results for a destination, a check-in/check-out interval, and an adult guest count. Returned rows contain the displayed stay type and listing name, date context, available price fields, accommodation details, ratings, and review counts. The Actor returns up to 100 unique stays and can continue through available public result-page cursors within its bounded search.
This is a search-result snapshot, not a booking engine or a complete property-detail scraper. It does not promise every available stay in a destination, fetch guest review text, disclose host contact information, or return image URLs. Prices are displayed observations for the requested context and must be checked again before booking.
Contents
- Capabilities and use cases
- Input
- Output fields
- Real dataset example
- Limits and coverage
- Run and export
- Pricing and outcome policy
- Usage tips and data quality
- Use with AI and MCP
- Support
- FAQ
- Related searches
- Related Actors
- Resources and disclaimer
- 中文说明
Capabilities and use cases
- Search one destination and date interval per run, with
adultsused as guest context. - Keep flat date fields (
checkIn,checkOut,nights) beside each result so exports remain understandable outside Console. - Capture displayed
totalPrice,originalTotalPrice,perNightPrice,currency, andpriceQualifierwhen available, without silently forcing them into a single reconstructed quote. - Return accommodation details such as beds, bedrooms, bathrooms, and guest capacity where the search result exposes them.
- Preserve rating and review count as optional fields; missing numbers are not zero.
- Return a stable hashed
listingIdfor the result and deduplicate overlapping listings before storing the bounded set. - Include
photosCountas a preview-photo count only. No photo download, image URL array, listing URL, or host profile is promised by the current output.
Where it fits
Date-specific destination research: compare the public stay cards shown for the same destination and travel interval. Keep adult count consistent so the context remains meaningful.
Accommodation shortlists: review names, room details, and ratings before manually checking the current listing and booking terms. A dataset row is not a reservation or a guarantee of availability.
Price observation: track displayed price fields over repeated snapshots with the same inputs. Preserve the qualifier and currency rather than treating all numeric prices as interchangeable.
Market research: examine the supported sample of public results for a location. It is not a census of inventory, and the maximum 100 rows must not be described as every stay in a city.
Analytics exports: use the flat room and price columns in a spreadsheet while preserving the full JSON for missing values and original price context.
Input
| Field | Type | Required / default | Description and limits |
|---|---|---|---|
location | string | Required | Destination after trimming; non-empty and at most 80 characters. City, region, or neighborhood. |
checkIn | string | Required | Real calendar date in YYYY-MM-DD form. Select a suitable travel date. |
checkOut | string | Required | Real YYYY-MM-DD date after checkIn; interval must not exceed 90 nights. |
adults | integer | 2 | Adult guest count, 1–16. No separate children or infant input. |
maxItems | integer | 100 | Maximum unique stay results, 1–100. Not a guaranteed match count. |
Example input
{"location": "Istanbul","checkIn": "2026-12-01","checkOut": "2026-12-02","adults": 2,"maxItems": 5}
Required fields have no automatic target substitute. Optional defaults are shown above; explicit integer limits should stay inside the supported range. Use the input form for the current schema rather than assuming extra JSON properties are meaningful.
Output fields
| Field | Type | Description |
|---|---|---|
listingId | string | Stable hashed stay identifier; treat as opaque, not a native booking URL. |
title | string | Displayed stay type/location heading. |
listingName | string | Displayed listing name. |
subtitle | string | Short public result description; may be empty. |
location | string | Destination context requested for the search. |
checkIn | string | Requested arrival date, YYYY-MM-DD. |
checkOut | string | Requested departure date, YYYY-MM-DD. |
nights | integer | Length of the requested stay. |
guests | number|null | Displayed accommodation capacity when available; not the submitted adult count. |
bedrooms | number|null | Displayed bedroom count when available. |
beds | number|null | Displayed bed count when available. |
bathrooms | number|null | Displayed bathroom count when available. |
rating | number|null | Displayed guest rating. |
reviewCount | integer|null | Displayed review count; no review text is returned. |
totalPrice | number|null | Displayed total-price field for the requested context. |
originalTotalPrice | number|null | Original total price where shown; may be null. |
perNightPrice | number|null | Displayed nightly price; not necessarily totalPrice divided by nights. |
currency | string|null | Displayed currency code where available; not a conversion setting. |
priceQualifier | string|null | Displayed price context or qualifier, such as total. |
photosCount | integer | Count of available preview photos, not image URLs. |
Types describe the public record and its optional values, not a promise that every field is populated. The built overview selects a subset of these fields; full JSON is the source for complete inspection.
Real dataset example
This unchanged row was retrieved from a historical SUCCEEDED Apify run GJcFE14mmkgN0hDSM, started 2026-09-29T19:02:53.381Z, dataset O0TKapTcL75QslRFp. It is real output, not illustrative placeholder data. The run is historical and does not claim a new live execution of the latest build. Values may differ on a future run.
Historical input:
{"location": "Istanbul","checkIn": "2026-12-01","checkOut": "2026-12-02","adults": 2,"maxItems": 1}
Stored row:
{"beds": 2,"title": "Room in Fatih","guests": null,"nights": 1,"rating": 4.8,"checkIn": "2026-12-01","bedrooms": null,"checkOut": "2026-12-02","currency": "EUR","location": "Istanbul","subtitle": "Triple Room in old Town with Breakfast","bathrooms": 1,"listingId": "65f38debbb99392d5c9b","totalPrice": 57,"listingName": "Triple Room in old Town with Breakfast","photosCount": 6,"reviewCount": 59,"perNightPrice": 60,"priceQualifier": "total","originalTotalPrice": null}
Limits and coverage
Maximum 100 unique stays per run. Maximum date interval 90 nights. maxItems must be an integer from 1 to 100 and adults from 1 to 16. The destination is trimmed and limited to 80 characters. Both dates are required real calendar dates in YYYY-MM-DD; checkout must be after check-in. Unsupported or malformed input is handled as a zero-result SUCCEEDED run with OUTPUT, not a billable fabricated listing.
The Actor can follow public result-page cursors internally and deduplicate overlaps, but it remains bounded by page availability, page limits, the requested cap, and execution time. There is no customer input field for a cursor or a request to traverse an unlimited inventory. A partial search can deliver verified unique rows with a partial-result note; inspect the notes before calling it complete.
Only public search information is included. Missing room details and prices remain null; missing descriptions remain empty. guests is accommodation capacity where shown, not a guarantee that the requested adult party can book the property. photosCount is a count, not a promise of image files or URLs. No host phone numbers, host emails, private messages, exact street addresses, booking actions, or full review text are provided.
Displayed total and nightly prices can use different presentation contexts. The historical row has a one-night interval, totalPrice 57 and perNightPrice 60. It is deliberately reproduced unchanged: do not “repair” the result by forcing those fields to agree. Preserve both and the qualifier; taxes, fees, discounts, terms, and live availability require confirmation on the current booking page.
Stay comparison workflow
Define a reproducible search brief: destination, travel interval, adult count, and maximum results. Use the same brief when comparing repeated snapshots, and label each snapshot with its run time. If your study changes dates or traveler count, treat it as a new search cohort rather than a like-for-like price update.
Use listingId as an opaque matching key within your own analysis. Do not turn the hash into an invented native listing URL, and do not assume title or listingName is unique. Room counts can be missing, so a shortlist based on bedrooms should explicitly include an “unknown” group instead of discarding every null row without explanation.
Price analysis should retain every available numeric field plus currency and priceQualifier. Do not derive a mandatory total from a nightly amount or replace the returned total with your own multiplication. A null originalTotalPrice does not show that there was no discount; it shows no usable original-price value was returned. A one-night example with unequal total and nightly fields is a reminder that public card presentation is not a settled invoice.
For recurring monitoring, store the submitted adults value separately because the current output's guests field represents accommodation capacity, not that input. Inspect result notes for bounded or partial delivery. Keep a completeness flag in your downstream report based on the actual run rather than claiming that every accommodation in the destination was searched. Before any purchase, manually confirm the intended dates, guest acceptance, cancellation policy, fees, and current availability.
Run and export
Start in Apify Console
Open this Actor's Store page and select Try for free or Run. Sign in to your own Apify account, enter the documented input fields, and start a small run before increasing the result limit. The Actor does not require a separate target-service API key or a target-site login. An Apify account is still needed to execute it on the platform. A platform trial does not change the Actor's documented result cap or make third-party content unrestricted.
When the run ends, open its default dataset. The overview table is a convenient presentation of selected columns; it is not a promise that every record has every value. Open the full JSON dataset when you need to distinguish an empty array from an absent value, preserve types, or inspect columns that are not in the overview. The Actor output links named results and fullJson point to the overview and complete dataset respectively. These links are storage locations, not extra columns inside each result.
Export as JSON for typed integrations. Use CSV or Excel for manual analysis and review how arrays and missing values are represented before importing into a spreadsheet. XML is also available through Apify dataset export. Keep the original JSON alongside a spreadsheet export when your workflow depends on numeric prices, arrays, or explicit null values. A table cell that looks blank is not sufficient evidence that extraction failed.
Three API examples
These examples use standard Apify REST endpoints. Set APIFY_TOKEN locally to your own Apify API token before running them. Do not paste the token into a ticket, screenshot, public repository, shared notebook, or chat prompt. All request URLs are double-quoted so shell variables expand correctly and query-string ampersands do not split the command. The examples use Bearer authentication rather than embedding secrets in URLs.
1. Start a run and wait briefly for its status. The returned run object includes id, status, defaultDatasetId, and defaultKeyValueStoreId. A response after waitForFinish=60 may still say RUNNING; HTTP success is not proof that the Actor has finished. Replace illustrative travel dates with a suitable future interval when applicable.
curl --fail-with-body --silent --show-error --request POST \"https://api.apify.com/v2/acts/myagizm~airbnb-stays-scraper/runs?waitForFinish=60" \--header "Authorization: Bearer ${APIFY_TOKEN}" \--header "Content-Type: application/json" \--data '{"location":"Istanbul","checkIn":"2026-12-01","checkOut":"2026-12-02","adults":2,"maxItems":5}'
2. Read the exact run's status. Set RUN_ID to the data.id returned by example 1. Repeat this GET at a sensible interval while the run is READY or RUNNING. Only proceed to interpret final coverage after a terminal status is reported. Do not start a second run merely because the first wait period elapsed.
curl --fail-with-body --silent --show-error \"https://api.apify.com/v2/actor-runs/${RUN_ID}" \--header "Authorization: Bearer ${APIFY_TOKEN}"
3. Download that run's full dataset. Set DATASET_ID to data.defaultDatasetId from the same run. This retrieves JSON rather than the overview projection. An empty JSON array is possible; inspect the run and its OUTPUT record before deciding whether it means an input problem, a confirmed empty search, or a genuine processing failure.
curl --fail-with-body --silent --show-error \"https://api.apify.com/v2/datasets/${DATASET_ID}/items?format=json&clean=true" \--header "Authorization: Bearer ${APIFY_TOKEN}"
You can read the reason for a handled empty outcome in Console under the run's default key-value store, record OUTPUT. The REST resource for that record is https://api.apify.com/v2/key-value-stores/{defaultKeyValueStoreId}/records/OUTPUT; authenticate with your own token just as above. Do not substitute a dataset ID for a key-value-store ID: the run exposes both and they serve different purposes.
Integration checklist
Store the run ID, submitted input, execution time, dataset ID, and final status in your own job record. Fetch data from that exact dataset instead of using a mutable “last run” reference when multiple jobs may overlap. Decide how your application represents an empty successful result, and keep that state separate from a failed job. Deduplicate across runs in your own destination if repeated snapshots should update existing records rather than append indefinitely. The Actor's per-run cap is not a cross-run database constraint.
Handle API authentication and permission errors at the client layer. An HTTP 401 from the Apify API means you should check your token; it is not a target search outcome. Avoid an unconditional retry loop that repeatedly launches billable successful runs. A bounded retry of a genuine transient failed request can be reasonable, but first confirm the original run's state. A client timeout can occur even while the original run continues on Apify.
Pricing and outcome policy
The pricing model is pay per event, with the stored dataset item as the result event. The current snapshot rate is $0.0008 per stored result, equivalent to $0.8000 per 1,000 stored results. Check the Actor's live Pricing tab for the rate applicable when you run it; platform pricing, plan terms, and any other account-level charges are governed by Apify. The quoted result rate is not a guarantee of a fixed total account invoice.
Request limits describe an upper bound, not a reservation of that many successful results. A requested maximum does not mean the search will find that many matches. Only stored result rows trigger the documented result event. A zero-row handled input error has zero result charges; a confirmed no-results outcome also has zero result charges. The absence of a result event should not be confused with an assertion about every possible platform or account fee.
Platform schema validation may reject malformed input before a run starts; the following policy applies to handled runtime input errors after a run is created.
Input errors finish SUCCEEDED with no results and no charge; see OUTPUT for the reason. Handled, explicitly classified missing-target or no-results outcomes likewise finish successfully with zero dataset rows and an explanatory OUTPUT record. The errorType vocabulary can include INPUT_ERROR or INVALID_INPUT, NOT_FOUND, and NO_RESULTS, depending on the Actor. Read the supplied message and hint rather than treating every SUCCEEDED run as a non-empty dataset.
Access denial, network interruptions, timeouts, and extraction/parsing faults are not silently re-labelled as a legitimate empty search. A genuine processing failure can remain FAILED. Do not interpret an unexplained empty response as proof that no matching public content exists. When there is partial verified delivery, review the run's notes and stored rows instead of assuming the requested cap was reached. For billing questions, share the exact run ID and the number of stored rows, not only a screenshot of the input limit.
Usage tips and data quality
- Keep comparable inputs together. Preserve the target, location wording, guest context, dates where supported, and result cap with each export. A later result may differ because the public page changed, not because an earlier row was incorrect.
- Use a small pilot. Validate that the returned fields fit your intended workflow before scheduling recurring jobs or requesting the maximum supported batch. Test the same export format that your production consumer will use.
- Treat optional fields explicitly. Preserve
null, empty text, and empty arrays instead of converting them all to zero. A missing price is not a free stay; a missing review count is not evidence of no reviews; an empty contact array means no value was captured for that category. - Retain raw values. Store the returned currency, displayed label, URL, and other context before normalizing data. Changes to formatting should happen in your downstream model, not by assuming all destinations or websites use the same conventions.
- Avoid unsupported controls. Adding undocumented dates, cookies, pagination tokens, filters, or other arbitrary JSON properties does not create a supported feature. Use only the input fields listed in this README and the Actor's current input form.
- Review before action. Public search cards and contact pages can be incomplete or outdated. Verify a booking decision or a contact action against the current public page; the Actor provides structured observations, not a commercial guarantee.
- Schedule deliberately. Apify saved tasks and schedules can reuse your chosen input, subject to your account's available features. Choose a cadence appropriate to the data, and review empty and failed runs separately rather than masking them in an aggregate success counter.
- Control retention. Export important results to your own authorized storage and apply your own retention policy. Run-associated datasets may be subject to your Apify account's retention settings; a historical example is not a promise of permanent storage availability.
Use with AI and MCP
This Actor can be used in an AI-assisted workflow through Apify's supported MCP tooling. Configure your MCP-capable client using the official Apify documentation and authenticate with your own Apify account. Tool names and setup details depend on the client and on the current Apify MCP server version; this README does not invent a dedicated tool name or claim that a target-site-specific MCP server is required.
A practical flow is: find this Actor by its Store identifier myagizm/airbnb-stays-scraper, inspect its current input schema, submit only supported fields, wait for the exact run to finish, and retrieve its dataset. Ask the assistant to cite the run and preserve the returned values when summarizing. Give it the destination or URL and the supported limits explicitly. Do not let an assistant infer unsupported search filters or convert starting/displayed prices into guaranteed checkout quotes.
An AI summary should keep missing values visible and distinguish a successful empty outcome from a transport failure. It should not manufacture records to reach the requested maximum or fill in prices, phone numbers, addresses, availability, or ratings that the dataset did not contain. Credentials belong in your client's secure configuration, not in a natural-language instruction or public output. MCP is an integration route to the Actor, not a broader data-collection permission or a way around the limits listed below.
Support
Use this Actor's Issues tab on Apify for reproducible problems and feature requests. Include the exact run ID, a minimal sanitized input, expected result, actual result, and whether you inspected the complete JSON dataset. For empty SUCCEEDED runs, quote the non-sensitive OUTPUT errorType, message, and hint if present. For access or timeout problems, provide the run's terminal status and relevant sanitized message.
Never share an Apify token, login cookie, password, private network URL, or unrelated personal information in a public issue. A successful historical sample helps explain the output shape; it does not prove that the same target still returns identical data today. Requests for extra result coverage or new fields are feature requests, not commitments that the current version supports them. Existing limits remain in force until the input schema and documentation explicitly change.
Related Actors
Use these separate Actors when they match your task. They are not automatic stages of this Actor, and running a sibling can have its own input requirements and charges.
Resources and disclaimer
- Actor Store page: current input form, pricing, runs, and Issues.
- Apify documentation: Console, tasks, schedules, storage, and integrations.
- Apify API reference: authentication, run status, dataset export, and key-value-store records.
- Apify MCP documentation: current supported MCP setup.
This Actor is an independent data-collection utility, not an endorsement, booking service, contact verification service, or official product of the websites named in its title or examples. Trademarks belong to their respective owners. Public visibility does not remove privacy obligations, website terms, content rights, or restrictions on reuse. You are responsible for ensuring that your collection, storage, analysis, outreach, and republication are lawful and authorized.
Do not use the Actor to bypass authentication or access restrictions, conduct unlawful spam campaigns, or make unsupported claims about people or properties. Returned data is an observation of public content at run time and can become outdated. Confirm important decisions using the current relevant page. The example below is a real historical dataset row, not a guarantee of present availability, an instruction to contact the listed people, or permission to reuse content beyond applicable rights.
FAQ
1. Are travel dates required?
Yes. Both checkIn and checkOut are required real YYYY-MM-DD dates, with checkout after arrival.
2. Can I request a stay longer than 90 nights?
No. The supported interval is at most 90 nights; invalid input is handled with zero rows and OUTPUT.
3. Can I fetch more than 100 stays?
Not in one run. maxItems is capped at 100 unique results; this is not an unlimited inventory endpoint.
4. Is there a cursor input?
No. Available public pagination is handled internally within the bounded run, not through a documented customer cursor field.
5. Does guests equal adults?
No. guests is returned accommodation capacity when displayed; adults is the input traveler context.
6. Can I download the preview photos?
No. photosCount is the number of preview photos; image URLs are not returned.
7. Why can total and nightly prices differ?
They are displayed fields and can have different contexts. Keep both exactly as returned and verify the current booking page.
8. Is a listing URL included?
The current documented dataset does not include one. Do not construct a native URL from the hashed listingId.
9. Can I filter by amenities or children?
Those controls are not current input fields. Supported inputs are destination, dates, adults, and maxItems.
10. Are missing ratings zero?
No. Missing numeric data remains null; preserve the difference between unavailable and zero.
11. Do I need a target-site account or separate API key?
No target-site login or separate target-service key is required for the documented public data. Apify execution and API calls still use your own Apify account and API token.
12. Why did SUCCEEDED return an empty dataset?
Handled input errors and explicitly classified missing or empty outcomes can succeed with zero rows. Read OUTPUT for the errorType, message, and hint; success is not a non-empty-data guarantee.
13. Are handled invalid inputs billed?
No result rows are stored and no result event is charged for the handled input-error outcome. Consult Apify separately for platform and account billing terms.
14. Will every genuine processing error also say SUCCEEDED?
No. Access denial, network, timeout, and parsing faults can remain FAILED. They must not be confused with a confirmed legitimate no-results outcome.
15. Is the requested maximum guaranteed?
No. It is an upper limit. Public content availability, bounded coverage, optional fields, and execution constraints can yield fewer rows.
16. Can I export CSV or Excel?
Yes, using Apify dataset export. Keep JSON when arrays, null values, or numeric types matter, and check how your spreadsheet handles those values.
17. Why is a field not visible in the overview table?
The table is a selected-field view. Read the full JSON dataset before concluding that a field was not returned, and preserve optional missing values as missing.
18. Can I use schedules and saved tasks?
You can use Apify platform tasks and scheduling features available to your account. Reuse valid inputs and review changes, empty outcomes, and pricing before running repeatedly.
19. What should I include in a support request?
The exact run ID, sanitized input, actual versus expected output, final status, and non-sensitive OUTPUT explanation. Never include API tokens or private credentials.
20. May an AI assistant fill missing values or infer unsupported fields?
No. Ask it to summarize actual rows, preserve missing values, and respect the exact schema. MCP access does not add features or permission to bypass limits.
Related searches
Airbnb stay search, date-specific accommodation scraper, vacation rental price snapshot, public stay ratings, accommodation room details, unique stay dataset. These terms describe supported research contexts, not additional input fields or a promise of broader coverage.
中文说明
Airbnb 住宿搜索 — 日期、展示价格与住宿详情
按目的地、入住与退房日期、成人数量搜索公开住宿结果。返回记录包含展示的住宿类型和房源名称、日期上下文、可获得的价格、房间信息、评分和评论数量。最多返回 100 条唯一住宿,并可在有限搜索范围内沿可用的公开结果分页游标继续检索。
这是搜索结果快照,不是预订系统,也不是完整房源详情抓取。它不保证列出目的地所有可订住宿,不读取评论正文,不披露房东联系方式,也不返回图片 URL。价格是请求上下文中的页面观察值,预订前必须再次确认。
中文目录
能力与用途
- 每次运行搜索一个目的地和日期区间,
adults用作成人入住上下文。 - 每条结果保留平铺日期字段
checkIn、checkOut、nights,使离开控制台的导出仍可理解。 - 若页面提供,捕获
totalPrice、originalTotalPrice、perNightPrice、currency、priceQualifier,不会暗中把它们重构成一个保证报价。 - 返回公开搜索卡片可见的床位、卧室、浴室和容纳人数等住宿详情。
- 评分与评论数是可选值,数字缺失不等于零。
- 返回稳定的哈希
listingId,在保存有限结果前对重叠房源去重。 photosCount仅表示预览照片数。当前输出不承诺照片下载、图片 URL 数组、房源 URL 或房东资料。
适用场景
指定日期目的地研究: 比较同一地点和旅行区间展示的公开住宿卡片,并保持成人数量一致。
住宿候选清单: 查看名称、房间信息和评分后,人工检查当前房源与预订条款。数据行不是预订,也不保证仍有房态。
价格观察: 在相同输入下重复采样展示价格,保留价格限定词与币种,不把所有数值视为同一种报价。
市场研究: 分析受支持范围内的目的地公开样本,不把最多 100 行描述成城市全部住宿库存。
分析导出: 在表格中使用平铺房间和价格列,同时保留完整 JSON,以便处理缺失值和价格上下文。
输入字段
| 字段 | 类型 | 必填 / 默认值 | 说明与限制 |
|---|---|---|---|
location | string | 必填 | 去除首尾空格后非空,最多 80 字符;可使用城市、地区或社区。 |
checkIn | string | 必填 | 真实日历日期,格式 YYYY-MM-DD;应选择合适旅行日期。 |
checkOut | string | 必填 | 真实 YYYY-MM-DD 日期,晚于入住;时长不能超过 90 晚。 |
adults | integer | 2 | 成人数量,1–16;没有单独儿童或婴儿输入。 |
maxItems | integer | 100 | 唯一住宿结果上限,1–100;不保证达到该数量。 |
输入示例
{"location": "Istanbul","checkIn": "2026-12-01","checkOut": "2026-12-02","adults": 2,"maxItems": 5}
必填字段没有自动替代目标;可选默认值如上。显式整数限制必须位于支持范围内。当前输入结构以表单为准,不要假设额外 JSON 属性有意义。
输出字段
| 字段 | 类型 | 说明 |
|---|---|---|
listingId | string | 稳定哈希住宿标识,应作为不透明值使用,不是原生预订 URL。 |
title | string | 展示的住宿类型或位置标题。 |
listingName | string | 展示的房源名称。 |
subtitle | string | 公开搜索结果简述,可能为空。 |
location | string | 搜索请求中的目的地上下文。 |
checkIn | string | 请求入住日期,YYYY-MM-DD。 |
checkOut | string | 请求退房日期,YYYY-MM-DD。 |
nights | integer | 请求住宿的晚数。 |
guests | number|null | 可获得时的住宿容纳人数,不是提交的成人数。 |
bedrooms | number|null | 可获得时的卧室数。 |
beds | number|null | 可获得时的床数。 |
bathrooms | number|null | 可获得时的浴室数。 |
rating | number|null | 展示的住客评分。 |
reviewCount | integer|null | 展示的评论数量,不返回评论正文。 |
totalPrice | number|null | 请求上下文的展示总价字段。 |
originalTotalPrice | number|null | 展示时的原总价,可能为 null。 |
perNightPrice | number|null | 展示的每晚价格,不一定等于总价除以晚数。 |
currency | string|null | 可获得时的展示币种代码,不是货币转换设置。 |
priceQualifier | string|null | 展示的价格上下文或限定词,例如 total。 |
photosCount | integer | 可用预览照片数量,不是图片链接。 |
类型描述公开记录及可选值,不保证每个字段都填满。构建中的概览选择部分字段;需要完整检查时应读取全部 JSON。
真实数据集样例
以下行原样读取自历史 SUCCEEDED Apify 运行 GJcFE14mmkgN0hDSM,启动时间 2026-09-29T19:02:53.381Z,数据集 O0TKapTcL75QslRFp。它是真实输出,不是占位演示。此证据属于历史运行,不声称刚刚对最新构建执行了新测试;未来运行的值可能变化。
历史输入:
{"location": "Istanbul","checkIn": "2026-12-01","checkOut": "2026-12-02","adults": 2,"maxItems": 1}
已存储数据行:
{"beds": 2,"title": "Room in Fatih","guests": null,"nights": 1,"rating": 4.8,"checkIn": "2026-12-01","bedrooms": null,"checkOut": "2026-12-02","currency": "EUR","location": "Istanbul","subtitle": "Triple Room in old Town with Breakfast","bathrooms": 1,"listingId": "65f38debbb99392d5c9b","totalPrice": 57,"listingName": "Triple Room in old Town with Breakfast","photosCount": 6,"reviewCount": 59,"perNightPrice": 60,"priceQualifier": "total","originalTotalPrice": null}
限制与覆盖
每次最多 100 条唯一住宿,日期区间最长 90 晚。 maxItems 必须是 1–100 的整数,adults 必须是 1–16 的整数。目的地去除首尾空格后最多 80 字符。两个日期均为必填的真实 YYYY-MM-DD 日历日期,退房必须晚于入住。不支持或格式错误的输入会作为零结果 SUCCEEDED 运行处理并提供 OUTPUT,不会编造可计费房源。
Actor 可在内部沿公开结果分页游标继续查询并对重叠记录去重,但仍受可用页面、分页限制、请求上限和运行时间约束。没有让客户提交游标或遍历无限库存的输入字段。部分搜索可能返回已验证唯一行及部分结果备注,判断完整性前应查看备注。
仅包含公开搜索信息。缺失房间与价格值保持 null,缺失描述保持空文本。guests 在可获得时表示住宿容纳人数,不保证请求的成人组合可预订。photosCount 是计数,不承诺图片文件或 URL。不会提供房东电话、邮箱、私信、完整街道地址、预订操作或评论正文。
展示总价和每晚价格可能具有不同呈现上下文。真实历史行的日期是一晚,totalPrice 为 57,perNightPrice 为 60。样例故意原样保留,不能强行“修复”为一致数字;应保存两个值和限定词。税费、费用、优惠、条款和实时房态须到当前预订页面确认。
住宿比较流程
先定义可重复的搜索简报:目的地、日期区间、成人数和结果上限。重复快照比较应保持输入一致,并为每次结果标注运行时间。如果改变日期或人数,应视为新搜索组,不是同条件价格更新。
在自己的分析中将 listingId 作为不透明匹配键,不要把哈希拼成虚构的原生房源链接,也不要假设 title 或 listingName 唯一。房间数可能缺失,按卧室筛选的候选名单应保留明确的“未知”类别,而不是无解释地删除所有 null 行。
价格分析应保留所有可用数值、币种和 priceQualifier。不要从每晚价格强制推算总价,也不要用自行乘法替换返回总价。originalTotalPrice 为 null 不能证明没有优惠,只说明没有返回可用原价。单晚总价和每晚价不一致的样例提醒我们,公开卡片不是结算发票。
定期监测时,应单独保存提交的 adults;输出 guests 表示住宿容纳人数,并非该输入。检查结果备注是否说明有限或部分交付。下游报告的完整性标记应根据实际运行设置,而不是声称查遍了目的地所有住宿。购买前应人工确认日期、入住人数、取消政策、费用和当前房态。
运行与导出
在 Apify 控制台启动
打开本 Actor 的商店页面,选择 Try for free 或 Run,登录自己的 Apify 账户,填写本文列出的输入字段。首次运行建议使用较小的结果上限,确认数据适合你的工作流程后再扩大请求。本 Actor 不要求另行提供目标服务的 API 密钥,也不要求目标网站登录信息;但在 Apify 平台执行仍然需要 Apify 账户。平台试用资格不会改变本文的结果限制,也不会使第三方内容变成可无限制使用的数据。
运行结束后,打开该次运行的默认数据集。overview 表格只是部分字段的便捷展示,并不保证每条记录的所有字段都有值。需要区分空数组与缺失值、保留类型或检查未展示字段时,请查看完整 JSON。Actor 输出中的 results 和 fullJson 分别指向概览与完整数据集;它们是存储链接,不是每条结果中的额外数据列。
需要保留类型时,优先导出 JSON。手动分析可以使用 CSV 或 Excel,但应先确认数组和缺失值在导出后如何表示。Apify 也支持 XML 数据集导出。若后续逻辑依赖价格数值、数组或明确的 null,请在电子表格之外保留原始 JSON。表格中的空白单元格本身不能证明抓取失败。
三个 API 示例
下面使用标准 Apify REST API。运行前,请在本地将 APIFY_TOKEN 设置为自己的 Apify API 令牌。不要将真实令牌放进工单、截图、公开代码库、共享笔记或聊天提示。请求 URL 使用双引号,确保 shell 变量展开,并避免查询参数中的 & 拆分命令。认证通过 Bearer 请求头完成,而不是将凭据嵌入 URL。
1. 启动运行并短暂等待状态。 返回的运行对象包含 id、status、defaultDatasetId 和 defaultKeyValueStoreId。即使设置 waitForFinish=60,返回时也可能仍为 RUNNING;HTTP 成功不等于 Actor 已经执行完毕。住宿日期示例仅供说明,实际运行时应换成合适的未来日期。
curl --fail-with-body --silent --show-error --request POST \"https://api.apify.com/v2/acts/myagizm~airbnb-stays-scraper/runs?waitForFinish=60" \--header "Authorization: Bearer ${APIFY_TOKEN}" \--header "Content-Type: application/json" \--data '{"location":"Istanbul","checkIn":"2026-12-01","checkOut":"2026-12-02","adults":2,"maxItems":5}'
2. 查询这一条运行的状态。 将 RUN_ID 设置为第一步返回的 data.id。当状态为 READY 或 RUNNING 时,以合理间隔重复查询;只有收到终态后,才判断最终覆盖范围。不要仅因为等待时间结束就再启动一次运行。
curl --fail-with-body --silent --show-error \"https://api.apify.com/v2/actor-runs/${RUN_ID}" \--header "Authorization: Bearer ${APIFY_TOKEN}"
3. 下载同一次运行的完整数据集。 将 DATASET_ID 设置为该运行的 data.defaultDatasetId。此命令返回完整 JSON,而不是概览投影。响应可能为空数组;请结合运行状态和 OUTPUT 记录,判断是输入问题、已确认的空搜索,还是实际处理故障。
curl --fail-with-body --silent --show-error \"https://api.apify.com/v2/datasets/${DATASET_ID}/items?format=json&clean=true" \--header "Authorization: Bearer ${APIFY_TOKEN}"
对于已处理的空结果,可在控制台中打开该次运行的默认键值存储并查看 OUTPUT 记录。对应的 REST 地址格式为 https://api.apify.com/v2/key-value-stores/{defaultKeyValueStoreId}/records/OUTPUT,认证方式与上面相同。请不要把数据集 ID 当成键值存储 ID;运行对象同时提供两者,但用途不同。
接入检查清单
在自己的任务记录中保存运行 ID、提交的输入、执行时间、数据集 ID 和最终状态。多个任务可能重叠时,应读取准确的数据集,不要使用可变化的“最后一次运行”引用。业务系统应把成功但为空的结果与失败任务分开处理。如果重复快照应该更新已有记录,而不是不断追加,请在自己的目标库中执行跨运行去重。本 Actor 的单次结果上限不是跨运行数据库约束。
Apify API 的认证与权限问题应在客户端处理。例如 API 返回 HTTP 401,应检查自己的令牌,而不是把它解释成目标搜索无结果。避免无条件重试并反复创建可计费的成功运行。遇到真实瞬时故障可以有限重试,但先确认原运行状态;客户端超时并不意味着 Apify 上的原运行已停止。
价格与结果状态
本 Actor 采用 按事件计费,已写入数据集的结果行是结果事件。当前价格快照为 每条已存储结果 $0.0008,即 每 1,000 条 $0.8000。实际运行前请查看商店的实时 Pricing 页面;平台价格、账户计划及其他账户级费用由 Apify 管理。这里的结果单价不承诺账户总账单固定不变。
请求上限只是最多可返回的数量,不表示预先保留了相同数量的成功结果,也不保证能够找到那么多匹配项。只有已存储结果行触发本文说明的结果事件。已处理的输入错误为零行、零结果费用;已确认的无结果情况也不产生结果费用。没有结果事件,不等于对所有可能的平台或账户费用作出承诺。
平台输入架构验证可能在创建运行之前拒绝格式错误的输入;以下策略适用于创建运行之后由 Actor 处理的输入错误。
输入错误会以 SUCCEEDED 状态结束,无结果且不收费;原因请查看 OUTPUT。 被明确分类并处理的目标不存在或无搜索结果情况,同样以成功状态结束,数据集为零行,并提供 OUTPUT 说明。不同 Actor 的 errorType 可能使用 INPUT_ERROR 或 INVALID_INPUT、NOT_FOUND、NO_RESULTS。请读取返回的 message 和 hint,不要把每次 SUCCEEDED 都当成必然有数据。
访问拒绝、网络中断、超时以及提取或解析故障,不会被悄悄改写成正常的空搜索。真实处理故障可能仍为 FAILED。没有明确说明的空响应不能证明公开内容确实没有匹配项。若已返回部分经过验证的数据,应检查运行备注和实际行数,不要假定达到了请求上限。咨询计费时,请提供准确运行 ID 和已存储行数,而不是仅提供输入上限截图。
使用建议与数据质量
- 保留可比较的输入。 每次导出都记录目标、目的地写法、成人数量、受支持的日期和结果上限。后续结果不同,可能是公开页面变化,不代表之前的记录一定错误。
- 先小规模试用。 在设置定时任务或请求最大批次前,确认字段符合实际需求,并测试生产系统将使用的导出格式。
- 显式处理可选字段。 不要把
null、空文本和空数组全部转换为零。价格缺失不代表免费住宿;评论数缺失不代表没有评论;某个联系方式数组为空,只代表该类值未被捕获。 - 保存原始值。 在规范化之前,先保留币种、展示标签、URL 和上下文。不要假设所有目的地与网站使用相同格式。
- 不要添加未支持的控制项。 在 JSON 中加入未记录的日期、Cookie、分页令牌、筛选项或其他属性,并不会自动得到对应功能。只使用本文和当前输入表单列出的字段。
- 行动前复核。 搜索卡片和联系页面可能不完整或已过期。预订和联系行动应以当前公开页面为准;本 Actor 返回结构化观察结果,而不是商业保证。
- 合理安排周期。 Apify 保存任务和定时功能可复用输入,具体取决于账户支持的功能。应选择与数据变化相符的周期,并分别处理空运行和失败运行,不要用单一成功率掩盖两者差别。
- 控制留存。 重要结果应导出到自己的授权存储,并遵守自己的保留策略。运行关联数据集可能受 Apify 账户留存设置影响;历史样例不意味着存储永久可用。
AI 与 MCP 使用方式
本 Actor 可通过 Apify 支持的 MCP 工具接入 AI 辅助流程。请按照 Apify 官方文档配置支持 MCP 的客户端,并使用自己的 Apify 账户认证。工具名称和设置方法取决于客户端及当前 Apify MCP 服务器版本;本文不会虚构专用工具名,也不会声称需要目标网站专属 MCP 服务器。
推荐流程:按商店标识 myagizm/airbnb-stays-scraper 找到 Actor,检查当前输入结构,仅提交支持的字段,等待准确的运行结束,再读取其数据集。让助手在总结中注明运行并保留真实返回值,明确告诉它目标 URL 或目的地和结果上限。不要让助手推断未支持的筛选项,也不要把起始价格或展示价格改写成保证结算报价。
AI 总结应保留缺失值,并区分成功空结果与传输故障。它不应为了达到请求数量而编造记录,也不应填入数据集中没有的价格、电话号码、地址、房态或评分。凭据应放在客户端安全配置中,而不是自然语言指令或公开输出中。MCP 是调用 Actor 的接入方式,不是扩大采集权限或绕过产品限制的方法。
支持
可在本 Actor 的 Apify Issues 页面提交可复现问题或功能需求。请提供准确运行 ID、最小化且已脱敏的输入、预期结果、实际结果,以及是否检查过完整 JSON。对于空的 SUCCEEDED 运行,可引用非敏感 OUTPUT 中的 errorType、message 和 hint。访问或超时问题应附上运行终态和相关脱敏消息。
不要在公开工单中分享 Apify 令牌、登录 Cookie、密码、私有网络 URL 或无关个人信息。历史成功样例用于说明数据结构,并不能证明同一目标今天仍返回相同数据。扩大覆盖或新增字段属于功能请求,不代表当前版本已经支持;除非输入结构和文档明确改变,否则现有限制继续适用。
相关 Actors
以下是独立 Actor,适用时可单独选择。它们不是本 Actor 自动执行的步骤,分别运行可能有自己的输入要求和费用。
资源与免责声明
- Actor 商店页面:当前输入表单、价格、运行与 Issues。
- Apify 文档:控制台、任务、定时、存储与集成。
- Apify API 参考:认证、状态查询、数据集导出与键值记录。
- Apify MCP 文档:当前受支持的 MCP 配置方法。
本 Actor 是独立的数据采集工具,不是所述网站的官方产品、背书、预订服务或联系方式验证服务。商标归各自所有者所有。公开可见并不免除隐私义务、网站条款、内容权利和再次使用的限制。你应确保采集、存储、分析、联系和再发布行为合法且获得必要授权。
请勿用于绕过认证和访问限制、实施违法垃圾信息活动,或对个人与住宿作出数据不支持的结论。返回数据是运行时的公开内容观察,之后可能过期;重要决策应再次检查当前页面。下方样例是真实历史数据行,不保证现在仍有房态,不构成联系其中人员的指令,也不授予超出适用权利范围的内容使用许可。
常见问题
1. 日期是必填吗?
是。checkIn 和 checkOut 均必须是真实 YYYY-MM-DD 日期,退房晚于入住。
2. 能请求超过 90 晚吗?
不能。支持区间最多 90 晚,无效输入以零行和 OUTPUT 说明处理。
3. 能获取超过 100 条吗?
单次不能。maxItems 最多 100 条唯一结果,不是无限库存接口。
4. 有游标输入吗?
没有。可用公开分页在有限运行内部处理,没有供客户提交的游标字段。
5. guests 等于 adults 吗?
不等于。guests 是展示的容纳人数,adults 是输入的成人上下文。
6. 能下载预览照片吗?
不能。photosCount 只表示预览照片数量,不返回图片 URL。
7. 总价与每晚价为什么不同?
它们是展示字段,可能上下文不同;应原样保留并确认当前预订页面。
8. 会返回房源 URL 吗?
当前记录的数据集没有该字段,不能用哈希 listingId 构造原生链接。
9. 能按设施或儿童筛选吗?
当前没有这些输入,支持的是目的地、日期、成人数和 maxItems。
10. 评分缺失就是零吗?
不是。缺失数值保持 null,应区分不可获得与零。
11. 需要目标网站账户或另外的 API 密钥吗?
本文公开数据无需目标网站登录或另外的目标服务密钥;Apify 执行和 API 调用仍使用你自己的 Apify 账户与令牌。
12. 为什么 SUCCEEDED 但数据为空?
已处理的输入错误或明确分类的缺失、空结果可成功结束且为零行。请看 OUTPUT 的 errorType、message、hint;成功不保证非空。
13. 已处理无效输入会计费吗?
不会保存结果行或触发结果事件;平台与账户费用条款应另查 Apify。
14. 真实处理故障也会显示 SUCCEEDED 吗?
不会。访问拒绝、网络、超时、解析问题可能为 FAILED,不应与已确认的正常无结果混淆。
15. 请求最大值一定返回吗?
不一定。它是上限,公开内容、有限覆盖、可选字段和执行约束可能使行数更少。
16. 可以导出 CSV 或 Excel 吗?
可以,通过 Apify 数据集导出。数组、null 或数字类型重要时也保留 JSON,并检查表格如何处理这些值。
17. 为什么概览看不到某字段?
概览是选定字段视图。判断字段未返回前应查看完整 JSON,同时保持可选缺失值为缺失。
18. 能用定时和保存任务吗?
可使用账户支持的 Apify 任务与定时功能;复用有效输入,并在反复运行前检查变化、空结果与价格。
19. 支持请求需要什么?
准确运行 ID、脱敏输入、实际与预期输出、终态和非敏感 OUTPUT 说明;不要附 API 令牌或私有凭据。
20. AI 可以补齐缺失值或推断未支持字段吗?
不能。应总结真实数据、保留缺失值并遵循准确结构;MCP 接入不会增加功能或绕过限制的权限。
相关搜索
Airbnb 住宿搜索、指定日期住宿抓取、度假出租价格快照、公开住宿评分、房间详情、唯一住宿数据集。这些关键词描述受支持的研究场景,不是额外输入字段,也不保证更广覆盖。