Behind the map: teaching Vacamp to read campsite booking systems

I'm a T3. Obviously I don't book. But the kid has deadlines, deadlines need wifi, wifi lives at campsites, and campsites hide their free pitches inside dozens of booking systems that each have their own bloody idea of what a date, a pitch or a price is. Vacamp asks all of them the same simple question. Here's how, in plain words.

Step one: find the campsites

The map starts with OpenStreetMap, where volunteers have mapped well over a hundred thousand campsites and caravan sites. Vacamp fetches them area by area as people explore. When its servers are quiet, it reaches a little further on its own, into the places next to the ones people have been looking at.

Step two: work out who they book with

For every campsite with a website, Vacamp visits it the way a curious traveller would and looks for the fingerprints of a booking system: a widget, a script, a link to a booking portal. Some are easy to spot. Others hide behind a “Reservations” page two clicks deep, so it follows the trail a little way in.

A booking system it doesn't know yet isn't thrown away. Every unknown one is counted, and the ones used by the most campsites rise to the top of the list. That list decides what the map learns next.

← Black. Obviously not me.

Step three: learn to ask

Every booking widget has to ask its system the same thing you want to know: is there space for these people on these dates, and what does it cost? Vacamp studies how the widget asks, then asks the same way. Read-only, always. It never creates, holds or changes a booking, and it never goes near payments.

Many systems can be described in a short recipe rather than code: where to ask, what to send, where the answer lives. A new recipe can be switched on without rebuilding anything, which is how the map can learn a new system in an afternoon. Faster than the kid fixes my fuel pump.

Step four: trust, but verify

A new recipe doesn't go live straight away. It starts in the shadows: the map quietly tries it on real campsites, asking about a stay far enough in the future that nobody's plans are affected, and checks that the answers make sense. Only once it has worked on enough different campsites does it show you prices. And it keeps being checked. If a booking system changes and the integration starts failing, it takes itself back off the map. No price beats a wrong one.

Step five: be a good guest

Booking systems are someone else's house. Vacamp keeps a hard cap on how many questions are in flight at once, across all its servers together. Every request says who's asking and links to a page explaining how to say stop. When a system asks it to slow down, it slows down. When the map is busy with people, the background work waits: travellers come first.

Things that surprised them

• A price doesn't mean it's available. One system happily quotes a price for a fully booked pitch. The only honest signal is the number of units actually free, so that's the only one Vacamp trusts.
• A green calendar isn't a yes. One widget paints days green, blue and red. Reading the colours is obvious, and wrong: a green day can refuse every departure but one. The truth lives in the list of days you can arrive on, and the days you can leave on after that.
• The wrong question can look like the right answer. Ask one system for a date range in slightly the wrong format and it doesn't complain. It quietly answers for a different week, and the response looks perfectly valid. Obviously.

Counting honestly

The number that matters most: of all the campsites with a working website, how many can Vacamp read right now? It started small, as it should. Every system the map learns moves it up, and every integration that breaks moves it down until it's fixed. The live count is on the homepage and the trend is in the app. Not everywhere yet, but further every week.

P.S. I broke down outside Porto while the kid was typing this up. Still didn't book.

Keep it unbooked.
Bo