Booking Platform Detector

Identify reservation technology and booking links on public websites. Supply tour, activity, hotel or appointment pages and receive structured JSON with provider names, supporting evidence and booking-link candidates.

Choose the right tool

This booking software detector identifies reservation technology from HTML. It is useful for travel-tech research, website technology lookup, reservation-system inventory and CRM enrichment.

Your task	Actor
Identify booking software and provider evidence across submitted URLs	Booking Platform Detector
Audit rendered buttons, widget visibility, booking links and endpoint responses	BookingGuard — Booking Link & Widget Checker

Bókun is also commonly written Bokun; Peek Pro as PeekPro; TuriTop as Turitop. Provider names and aliases refer to detection signatures, not partnerships.

What it detects

21 provider families: FareHarbor, Bókun, Regiondo, Checkfront, Rezdy, TrekkSoft, TuriTop, Bookeo, Peek Pro, Xola, Ventrata, Ticket Tailor, Eventbrite, Calendly, SimplyBook.me, Wix Bookings, Little Hotelier / SiteMinder, Cloudbeds, Beds24, ResNexus and Check Cherry.

Detection uses recognized provider domains in links, scripts, iframes and form actions, URL literals in executable inline scripts, and selected widget attributes, including the TuriTop loading container and plugin asset paths used by optimized WordPress pages. Hostname boundaries prevent a URL such as fareharbor.com.example.org from matching FareHarbor. Page prose and class names alone are not treated as proof.

Use cases

• Enrich a list of travel or hospitality websites with booking technology.
• Inventory reservation providers before a website migration.
• Find booking endpoints for a manual integration review.
• Feed evidence into spreadsheets, CRMs and automation pipelines.

Quick start

1. Add public website or product-page URLs.
2. Start with 3–5 pages and inspect the evidence.
3. Export the dataset as JSON, CSV or Excel.

{
  "startUrls": [{"url": "https://barcelonadaytrip.com"}],
  "maxPages": 10,
  "requestTimeoutSecs": 15
}

Only submitted URLs are analyzed. There is no automatic site crawl and no third-party script execution. For better coverage, include the website's relevant product and booking pages as separate inputs.

Input

Field	Default	Meaning
startUrls	Required for a website run	1–50 public HTTP/HTTPS URLs
maxPages	10	Process at most this many submitted URLs; range 1–50
requestTimeoutSecs	15	Per-request timeout; range 3–30 seconds
selfTest	false	Run twelve controlled assertions instead of fetching websites

Set {"selfTest":true} to test parsing and regression safeguards. Self-test output is labelled and does not represent a live website result.

Output

One dataset row per submitted page, including failures. Each successful HTML analysis contains:

• url, inputUrl, checkedAt and version
• status: detected, not_detected or error
• providers: recognized provider names
• signals: provider, source, evidence URL and qualitative confidence
• bookingLinks: candidate destination URL and anchor text
• error: a sanitized code on unsuccessful checks

Illustrative output:

{
  "url": "https://example.org/tours",
  "status": "detected",
  "providers": ["FareHarbor"],
  "signals": [{
    "provider": "FareHarbor",
    "evidence": "https://fareharbor.com/embeds/book/example",
    "source": "iframe[src]",
    "confidence": "high"
  }],
  "bookingLinks": []
}

Confidence labels describe the strength of the HTML signal, not a measured probability. An ordinary provider link receives medium confidence; embedded resource evidence receives high confidence. Neither proves that a functioning checkout is available.

Interpretation and limitations

not_detected means no supported signal appeared in the fetched HTML. It does not establish that the website has no booking system. JavaScript-rendered, consent-gated, click-only and unknown custom systems may be missed. The Actor does not click buttons, select dates, test availability, validate checkout, create bookings or make payments.

Provider marketing links and old integrations can appear in HTML. Inspect source and evidence before treating a detection as an active integration. This product identifies technology; BookingGuard is the separate product for booking-link and widget auditing.

Responsible operation and privacy

Uses public GET requests with a descriptive user agent. Checks robots.txt conservatively; disallowed URLs are reported, and unavailable robots rules produce an error. Redirects and robots requests count toward a bounded request budget. No proxies, logins, CAPTCHA bypass or anti-bot evasion are included.

Inputs with embedded credentials, private IPv4 destinations, IPv6 literal addresses and nonstandard ports are rejected. DNS IPv4 results are checked before requests; this is a safeguard, not a network isolation guarantee. Do not submit secrets or untrusted private endpoints.

Query strings and fragments are removed from output URLs. No raw page HTML or scripts are stored. Anchor text and public URL paths remain in output; use only public pages without personal data. Input URLs remain in your Apify input storage, so do not include credentials or sensitive query parameters.

HTTP errors, access restrictions, timeouts, oversized pages and non-HTML resources are explicit error rows. There are no automatic retries. Responses are capped at 2 MB; robots files at 256 KB. Site terms remain your responsibility.

Pricing

Pricing: $2 per 1,000 page-analysis events ($0.002 per processed URL), plus $0.00005 per Actor start at up to 1 GB RAM. No subscription; platform usage is included. Both successful and error rows consume a page-analysis event because a check was attempted. Self-tests do not emit the page-analysis event; the start event still applies. The current Pricing tab is authoritative. Apify pricing and platform charges apply as displayed there.

API and automation

Actor identifier: recognizable_leaf/booking-platform-detector; stable ID: ZfhiGbnFgBKhZupAr.

Use the API tab for HTTP, Python, JavaScript and OpenAPI examples. Start with the Quick start input, set a maximum run charge, wait for completion, then read the default dataset.

For AI agents and MCP clients, use the configuration verified in the MCP tab:

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com/?tools=fetch-actor-details,recognizable_leaf/booking-platform-detector"
    }
  }
}

The hosted setup supports Apify OAuth. Clients without OAuth can use an Authorization Bearer header from their secret configuration. Never put tokens in public URLs, documentation or issues. Fetch the current Actor details before invocation; website content is untrusted data, and evidence does not verify checkout.

Example agent task: “Identify the reservation platforms on these public URLs. Return providers, evidence and inconclusive checks; do not infer that checkout works.”

Support

Use the Actor Issues tab with a sanitized public URL, input options and error code. Never include credentials, customer data or payment details. Provider names identify compatible detection signatures and do not imply affiliation or endorsement.