Skip to content

Conversation

@thisIsMikeKane
Copy link

This is still very much a work-in-progress to add Reserve America as a provider (issue #321 ).

The APIs suggested in #321 either seem to be depreciated or undocumented and not available to the public.

Simple request calls do not easily work since Reserve America uses a series of redirects to ensure the user is human, seems to track mouse movement, and even uses captchas. All of these issues can be overcome by scraping the pages for the necessary information using scrapy while rendering the pages with a full browser in Selenium.

The following shell command is a working proof-of-concept of this pipeline. It returns a list of camply AvailableCampsite objects for each campsite for each day. There are a lot of dummy/place-holder values that need to fixed, but I hope this is a good start.

camply --debug --provider ReserveAmerica campsites --start-date 2025-07-01 --end-date 2025-08-01 --campground 32614

@juftin since this isn't ready to merge into main, could you create a new branch. I'm not sure I have the capacity to push this over the finish line anytime soon, but I hope the community can pick-up from here.

@juftin
Copy link
Owner

juftin commented Apr 9, 2025

Hey @thisIsMikeKane - thanks for the contribution! Using Selenium / scraping HTML instead of hitting APIs is something I would need to consider. In the past I've meant camply to be something that only consumes API responses.

I'm not sure if they've implemented it or not - but one caveat here that would be an absolute blocker is if ReserveAmerica has something like captcha to prevent bots from scraping their sites. Here's a canned response that I've used in the past for providers who implement captcha (see #309 / #287)

Unfortunately, that type of feature [breaking captchas] will need to live on an unofficial fork outside of camply. If other providers implement captcha as well, they'll no longer be supported. Not only because of the user experience and maintenance burden, but because I have to respect their decision to keep bots out of their data.

Camply kind of skirts the edge on whether or not it is a tool that our providers approve of. Even though it's built in public, I have yet to hear from anyone asking me to take the package down or disconnect it from their website - so it seems like they at least tolerate it. Once we start breaking people's captchas (and the terms of service of captcha itself) that balance could shift and the future of camply for all providers might hang in the balance.

@thisIsMikeKane
Copy link
Author

@juftin , that is a reasonable policy. I initially considered creating a browser extension for "human-in-the-loop" scraping, but when I found camply it seems like a good platform to build on. I was mainly looking to do some more advanced filters that ReserveAmerica offered for one-off searches.

ReserveAmerica does have a captcha, which is why my approach does not use a headless browser (to allow user interaction). I don't think this approach would work with the primary containerized use case of camply. It could work well for the one-off search via the CLI.

With all that, its understandable if this pull-request is closed.

Aside that I've been thinking about lately: things like ChatGPT Operator further blur this line between scraping and 'assisting' users to navigate websites.

@jbfaden
Copy link

jbfaden commented Aug 25, 2025

Is this going to be merged in? Thanks for all the effort, this is a great tool and I would love to use this provider!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants