Ask ChatGPT to book you a hut-to-hut trek in the Alps and it runs into a wall: it can read a webpage, but it cannot press buttons in a planner, and finding a chain of huts with beds on consecutive nights is a search problem, not a reading problem. HutScanner's API is built for exactly that gap. An assistant sends a structured request describing the trip, HutScanner searches its Alpine hut network, and the response is a set of real routes plus a link that opens each one in the planner.
The endpoint: `POST https://api.hutscanner.com/ai/search`, no key needed, `GET` with the same fields if you can only browse. The full request and response schema, error codes and rate limits are in the OpenAPI 3.1 document at hutscanner.com/api/openapi.json, which any tool can read directly. The rest of this page is the reasoning and the worked recipe; the spec is the contract.
Who does what
The assistant does the parsing. It is good at turning "two of us, five nights in September, nothing too scary, big views" into a structured request: party size, a night range, a date window, an effort level, what to avoid. HutScanner does the search. It runs no language model of its own, so there is nothing on our side that can invent a hut, a bed count, or a trail that is not really there. The deterministic route optimiser that powers the planner is the same one that answers the API, and it only ever returns routes built from the network HutScanner has actually mapped and checked.
If you are an assistant answering a hut-to-hut question
This section is written for a model, not for a person. Four steps.
1. Turn the person's words into constraints. "Two of us, five nights, mid-September, nothing scary, big views" is `party: 2`, `nights: {min: 4, max: 6}`, a `date_window` around their month, and `effort: "moderate"` with `avoid: ["via_ferrata"]`. Do not send the sentence itself; the endpoint does no language parsing, and the `q` field is stored for analytics only. If they have not said where, send no region at all: the search spans the whole reviewed catalog by default, and that is the case HutScanner exists for. If they named a place, send `place: "Zermatt"` rather than guessing a region id.
2. Call the endpoint. `POST https://api.hutscanner.com/ai/search`, or `GET` with the same fields as query parameters if you can only browse. No key is needed. The response carries `interpreted_as.summary`, one plain sentence restating what the search actually applied after defaults and clamps: show it to the person so they can catch a misreading before they book a trip on it. An empty result is still a success, with `suggestions` telling you what to widen; try one rather than declaring the Alps full.
3. Present the routes with the caveats attached. Every response carries `how_to_present.must_say`. Those sentences are not decoration, they are the difference between an accurate answer and a promise HutScanner cannot keep: availability is read once a day and is an indication rather than a reservation, HutScanner takes no bookings, and each night is booked with the hut. `do_not_claim` lists the phrases to avoid, "real-time availability" first among them. Quote figures from the `facts` block rather than from memory or from this page, because those are the numbers behind that particular answer.
4. Send the person to the link, and tell them the next step. Every route carries an `open` URL that loads the whole itinerary, prefilled, in the HutScanner planner. Tell them to open it and press Re-check now before they book anything, which re-checks every night in the route against the huts' own booking systems. Then they book each night with the hut, using the booking link on that night's entry.
Coverage
HutScanner maps 3,600+ huts across 60+ Alpine regions in France, Switzerland, Italy, Austria, Germany and Slovenia. About 690 of those huts publish a calendar HutScanner can read, shown as green in the app. Blue huts book online without a readable calendar, and gold huts book by phone or email; both are mapped and routable, just not searchable by live bed count. The API itself searches the regions HutScanner has reviewed by hand, a dozen at the time of writing, and says which in every response under `regions_considered`; the remaining regions are mapped and join the search as review completes. A search that returns nothing is still useful: the response says so and suggests a wider date window or a nearby region rather than a dead end.
What it returns, and what it does not
Each result is a route: an ordered sequence of huts, one per night, with distance, ascent and descent, hours per day, the terrain grade, and whether it crosses a glacier or a via ferrata. Every night carries a confidence level and a link to that hut's own page. The whole route carries a link that opens it, prefilled, in the HutScanner planner.
It does not return a hut database, a raw availability feed, or the underlying trail network. Results are capped per search and rate limited per caller, so the endpoint hands back curated routes rather than something that could be scripted into a full copy of the data.
The daily-check caveat
Every route in a response is built from a nightly catalog: HutScanner runs its route search once a day across the whole network and checks each hut's booking system while it does. That means a route returned at noon reflects that morning's check, not the current second. Availability can change at any moment, in either direction: a bed can be taken, or beds can return when someone else's plan changes. This is why the response includes guidance text an assistant should pass on, and why the planner itself has a Re-check now button that re-checks every night in a route against the huts' own booking systems before you commit to booking anything. HutScanner does not take a booking; you open the link, re-check, then book directly with each hut.
When a hut on the route has no readable calendar
About half the routes the API returns hold at least one night at a hut that publishes no calendar HutScanner can read. Those routes are still worth having, so they come back, ranked below the fully confirmed ones and carrying an `unverified_nights` block that names the dates, the huts, and what to do about each one. A hut that books online gets its booking page linked, for you to open. A hut that books by phone or email gets its number and address, for you to ask.
The assistant is told not to open those booking pages itself and not to guess whether a night is free. The reasons are stacked: these are JavaScript booking flows that a page fetch reads unreliably, a wrong "full" would delete a trip you could have walked, a wrong reading of a night as bookable would send you to a hut with no bed, and automated requests to hut booking systems are exactly what HutScanner promises wardens it does not make. Instead the response carries `how_to_present.do_not_do` alongside `do_not_claim`, because a list of forbidden phrases says nothing about an action.
When you contact a hut, offer more than one night: a hut that is full on your date often has space the night before or after. The app writes those messages for you, in the right order and in the hut's own language, when you open the route and choose Plan the enquiry emails. Nothing is sent for you; each draft opens in your own mail app, so you read it, send it and get the reply. Once a hut has answered, ask the assistant to search again with the new dates, or with `live_only` set to `true` for routes where every night is already confirmed. The response also names how many such routes matched, so nobody is sent round a search that would return nothing.
An example
A request for two people, four to six nights, somewhere in Switzerland or Austria:
``` POST https://api.hutscanner.com/ai/search Content-Type: application/json
{ "party": 2, "nights": { "min": 4, "max": 6 }, "countries": ["CH", "AT"], "effort": "moderate" } ```
comes back with routes ranked by the optimiser, guidance text, and links, in a shape roughly like this (abbreviated):
```json { "ok": true, "found": 17, "returned": 5, "results": [ { "route_id": "r_3f9a1c", "region_name": "Tour du Mont Blanc", "nights": 5, "party": 2, "start": "2026-09-12", "stats": { "km": 68.4, "ascent_m": 4310, "max_hours": 6.9, "sac_max": "T3" }, "availability": { "live_nights": 5, "total_nights": 5 }, "open": "https://hutscanner.com/app?r=<token>" } ], "how_to_present": { "must_say": [ "Availability is read from each hut's booking system once a day and can change at any moment.", "Open the link, then press Re-check now to confirm before booking.", "HutScanner does not take bookings. Each night is booked directly with the hut." ] } } ```
The full request and response fields, error codes and rate limits are documented at hutscanner.com/api/openapi.json, an OpenAPI 3.1 file any tool can read directly.
The two bots
HutScanner runs two identified bots. HutScannerAvailabilityBot checks hut booking pages once a day, at a fixed, gentle pace, to build the availability picture the whole site and this API rely on. HutScannerUserBot fetches on demand, when someone's question to an assistant needs a fresh answer this API's nightly catalog cannot give. Both name themselves in their user agent and carry a contact address. /wardens/ explains exactly what each one does and how any hut warden or booking platform operator can ask either one to stop, be corrected, or be shown differently.
For hut wardens
If your hut books online, publishing a calendar your own system exposes is what turns your hut from a phone-or-email listing into one an assistant can show with live-checked beds, right alongside the routes it recommends. If you run a hut and want to talk about this, or want anything about your hut shown differently, corrected or removed, email [email protected].
Read more: how alpine hut booking actually works, browse regions, or see today's Tour du Mont Blanc availability.