camply polls booking APIs for you so a sold out campsite can be booked the second it returns

A poller for cancellations, not a booking engine

camply is a tool to help you book a campsite online. The problem it names is specific: finding reservations at sold out campgrounds can be tough. Popular sites release inventory on a cancellation basis, and the window between a site becoming available and someone else taking it is short.

So camply searches thousands of campgrounds across the world via the APIs of booking services like recreation.gov. It continuously checks for cancellations and availabilities to pop up. Once a campsite becomes available, camply sends you a notification to book your spot.

That last word matters. The tool does not book for you. It narrows the timing problem by watching the API for you, and the act of booking stays with you. That is the correct division of labour, since a reservation with a payment step and a vehicle and site selection is not something a script should decide on your behalf.

The implementation is a Python package with a click based command line, packaged with hatchling, and classified in its own metadata as Development Status :: 5 - Production/Stable with an MIT licence. The project description calls itself the campsite finder, and its own tagline in the package metadata is a camping emoji followed by the tool name.

Providers are the core abstraction, and one of them covers a lot of ground

A provider is an online booking service that lists camping and recreation inventory. camply works with a number of them, and the provider list is the most interesting part of the project because it shows how much of the fragmented booking world has been packaged behind one interface.

RecreationDotGov searches on Recreation.gov for Campsites and is the default provider. Yellowstone searches YellowstoneNationalParkLodges.com for Campsites. ReserveCalifornia searches ReserveCalifornia.com for California State Parks. AlabamaStateParks, ArizonaStateParks, FloridaStateParks, MinnesotaStateParks, MissouriStateParks, OhioStateParks, VirginiaStateParks, FairfaxCountyParks, MaricopaCountyParks, and NorthernTerritory cover individual state and regional systems, with the NorthernTerritory provider searching the Australian Northern Territory booking site.

GoingToCamp is the interesting one because it is a single provider covering many separate reservation sites. It reaches Parks Canada through reservation.pc.gc.ca, Washington State Parks, Wisconsin State Parks, Michigan State Parks, BC Parks, Maryland State Parks, Nova Scotia Parks, Manitoba Parks, New Brunswick Provincial Parks, Newfoundland and Labrador Provincial Parks, and a long list of Ontario and Quebec regional operators including Long Point Region, Algonquin Highlands, Maitland Valley, Saugeen Valley, St. Clair Region, Tacoma Power Parks, and Gatineau Park.

The point of the abstraction is that the CLI does not change when the underlying reservation site does. Each provider knows its own site, and the campsite search command works the same across all of them.

Three commands cover searching, from areas down to individual sites

The command surface is organised as a hierarchy, and understanding the hierarchy is the whole tutorial.

A recreation area contains campgrounds, and a campground contains campsites. Searching for a specific recreation area looks like this:

camply recreation-areas --search "Glacier National Park"

Searching for campgrounds, which contain campsites, adds a state filter:

camply campgrounds --search "Fire Lookout Towers" --state CA

Searching for available campsites is the third level, and this is the command that starts watching. The example searches for available campsites, gets a notification whenever one becomes available, and continues searching after the first one is found:

camply campsites \
    --rec-area 2725 \
    --start-date 2023-07-10 \
    --end-date 2023-07-18 \
    --notifications silent \
    --search-forever

Two flags carry most of the weight here. The date range selects the nights you want, and --search-forever is what turns a one-shot query into a watcher. Without it, camply reports what is currently available and stops.

The --rec-area value identifies the recreation area, which is why the previous commands matter as a setup step rather than an alternative.

Notifications run through ten channels, and the CLI wires itself into your shell

The example above uses silent notifications, which is useful for a first run because it avoids sending you a message for every candidate it finds. In production the tool supports a much wider set of channels: Email, Slack, Twilio for SMS, Pushover, Pushbullet, Ntfy, Apprise, Telegram, and Webhook, in addition to silent.

That list maps onto the dependency list in the project metadata. The apprise, twilio, and trogon packages are declared as optional extras, with an all group that installs all three. apprise covers the Apprise channel, twilio covers SMS, and trogon is the shell completion tool, which explains the tui extra grouping it sits in.

Shell completion is worth a mention because it is a real quality of life feature and it is wired in at the container level too. The Docker image generates a completion script with _CAMPLY_COMPLETE=bash_source camply and writes it into the home directory so it can be sourced from .bashrc.

One caveat on notifications is not documented, so it is worth stating: a channel you have not configured cannot notify you. If you use a channel that requires an account, a token, or a webhook URL, test that path with a short, non-forever search before relying on it for a site you care about.

The Docker image runs uv, locks dependencies, and defaults to a help command

camply is published on Docker Hub as juftin/camply, and the Dockerfile shows a modern Python packaging setup. The base image is python:${PYTHON_VERSION}-slim-bookworm with a default of 3.12, and it installs jq as the only system package.

Dependency installation is handled by uv, mounted in from ghcr.io/astral-sh/uv rather than installed by pip. The environment sets UV_LINK_MODE=copy, UV_LOCKED=1, and UV_COMPILE_BYTECODE=1, and the sync runs with --no-install-project --no-dev so that only runtime dependencies are resolved before the project itself is copied in. The second sync then installs the project with --extra all, which is how the notification extras end up in the image.

The final steps are small but telling. The virtualenv bin directory is prepended to PATH, HOME is set to /home/camply and created, and the working directory is moved there. The logging handler is selected with the CAMPLY_LOG_HANDLER environment variable, set to PYTHON in the image.

The default command is camply --help, which is the right default for an image that may be run either interactively or as a one shot container invocation with a specific subcommand.

Dependencies reveal the resilience and rate limit design

The runtime dependency list in the project metadata is short and tells you how the tool behaves under a flaky network.

tenacity provides the retry logic, and requests handles the HTTP calls. ratelimit enforces request pacing, which matters because the whole premise is repeated polling against public reservation APIs. Click and rich-click provide the command line with formatted output, rich handles the terminal rendering, pydantic~=1.10.22 models the API responses, pandas handles the tabular result data, pyyaml and tomli cover configuration, python-dotenv loads environment variables from a file, and fake-useragent generates plausible user agent strings.

The combination of tenacity and ratelimit is the interesting pair. Any tool that polls an API on a schedule has to survive transient failures without hammering the endpoint, and having both a retry library and a rate limiter as explicit dependencies means the author treated that as a first class concern rather than an afterthought.

The Python support floor is 3.9, and the classifiers list 3.9 through 3.14, with requires-python set to >=3.9,<4. The build backend is hatchling, and the project ships a uv.lock file, so a reproducible environment is part of the shipped artifacts rather than something a user has to construct.

Where camply stops, and how the project is maintained

Two limits are clear from what the project describes.

The first is that camply watches and notifies, and the booking is still yours to make at speed. If a site releases a campsite at the exact moment you are asleep, a push notification does not book it. There is no queueing, no auto-booking, and no hold on inventory described anywhere. The value is in the hours you are not staring at a browser, not in the seconds of the booking itself.

The second is provider coverage. Each provider targets a specific reservation site with its own API, and the site can change. A provider that the author has not built, or a site that changes its API, is simply not available to you. The project fixes this by adding providers over time, and the provider list published with the project is the honest measure of what works today.

On maintenance the picture is healthy. The last push was on 2026-10-19, and three tagged releases came out in 2026: v0.34.4 on 2026-10-14, v0.34.3 on 2026-09-25, and v0.34.2 on 2026-05-24. The version is still below 1.0, which for a tool whose interface is a set of CLI flags and flags do occasionally move, is worth noting if you script it.

The licence is MIT, which is permissive and short, and appropriate for a personal utility. The project also uses semantic-release for versioning, has a pre-commit configuration, a Taskfile for task automation, and a docs site built with MkDocs, so it is maintained with the tooling a maintained Python project would use.

Editorial conclusion

camply fits an individual camper or a small group watching a specific campground for a cancellation, especially on recreation.gov and on the state park providers it already knows how to query. It does not fit anyone who needs to hold a reservation for a large group, and it does not remove the need to book quickly once it notifies you. Before running it continuously, confirm your booking site allows the polling this implies, and check that your notification channel is one of the supported ones, since a silent channel means a missed site.

Frequently asked questions

Official sources

1. juftin/camply on GitHub
2. License: MIT
3. Project website
4. README
5. Releases