API, again...

[Greg Akins]

Looking back, there is a history of people asking about API, or downloading the Stream Data

Has anything changed since the last thread on that topic ( May 2025)

It seems like there is no interested in providing Stream data for consumption anywhere except via American Whitewater.   

Am I understanding correctly?

Greg Akins

[Ian K]

Hi Greg — I'm Ian, a paddler and developer based in Colorado, just joining the group. Your post caught my eye because the API question is exactly why I'm here.

You're understanding it correctly, and you're not alone in the frustration. The data was built by the community over decades, and I think most developers in this space — myself included — would love a way to build on top of it responsibly rather than starting from scratch. I understand there are real operational and legal reasons why open access is complicated, and honestly infrastructure costs and development capacity probably play into it too. But that's exactly the kind of problem that people like us in the community have a lot of ambition to help solve — if AW ever wanted to explore a path toward a public API, there's no shortage of technically capable paddlers who would show up for that effort.

I've been experimenting building a streamflow app that works around that gap for now, using OpenStreetMap, USGS, and other water data APIs as a foundation — with the architecture kept open enough to plug into AW's data if that ever becomes possible. The core feature is AI-assisted automated trip recording, with trip reports formatted for direct submission back to the places paddlers already share — AW trip reports, social media, and other whitewater forums and river data apps. Along the way I've been thinking about whether an open standard for river data communication between back-end APIs could work — something that layers in more than just automated streamflow readings and includes reach and river-travel information as well.

I've also been wondering whether AW would have any interest in certain integration ideas I've been developing — specifically an AI-assisted moderation layer that could help reduce the manual burden on StreamTeam volunteers by automating some of the validation and scoring of incoming trip reports and reach corrections before a human ever has to look at them.

I'd love to connect with other technically-minded paddlers who share this frustration. If there are others in this group who have tried to build on AW's data or have thoughts on where the gaps are, I'm very interested in that conversation.

— Ian

[Owen Coutts]

Hi All,

This has indeed come up a number of times. From my point of view there are both technical and organizational reasons to think about doing this. The difficulty of course is volunteer capacity to build and maintain this as well as the cost. Ironically this message receives me as I'm wrestling with shipping a breaking change to our internal APIs for our mobile app! 

In my mind, there are a couple technical issues:

• We're in the process of rewriting the infra that supports the river data. There is still a single server / single database that has code written in the 90s that still supports much of the site. It's brittle and I'm worried about putting more load on it.
• Cost - to make it affordable for a non profit, we have a ton of caching on the AW site. Frankly, we need to be spending less, not more. We'd have to rethink a bunch of stuff to figure out how to serve this data in a cost optimized way.
• Support - My experience working on supporting APIs that are used by other companies / products is that it's a pain. As a volunteer, I'd rather spend my time improving features in this app rather than supporting an API.
• Development Speed - There are a lot of things that need to change about this app / database to help it continue to be relevant. As an example, there are bugs in the schema right now that will lead to unexpected results. We need to rebuild the way we manage things like photos and trip reports and doing so with APIs on top of it would only make it harder.

This doesn't even begin to contemplate the question of what would this API enable and how would it work which feel like questions the organization would need to answer.

In terms of some of the things you brought up, I'm curious to hear more about what you're thinking in terms of an assisted moderation layer! I'm sure that could be quite useful / valuable if integrated into AW. Right now we're working on getting an index stood up for changes so that we can actually look through them in a reasonable way. 

In terms of paddlers showing up who want to help build a better product for American Whitewater, I haven't seen a ton of folks who are excited about making improvements and getting AW into a more sustainable place but that being said, I haven't has as much time as I would like to support people in this type of help as I would like.

Owen

[Ian K]

Hi Owen — thank you for the honest breakdown, that kind of context is hard to find from the outside. I'd love to find a way to be useful here rather than add to the noise.

You mentioned development capacity and cost as core constraints, and I understand that better now. I bit my tongue a little when I said there's no shortage of technically capable paddlers willing to help — it may be more accurate to say there's no shortage of people who *want* to contribute. Whether that translates into sustained, useful effort is a different question entirely, and I respect that past experience may have been mixed.

I do think there are angles worth exploring on each of the constraints you mentioned, but I'd rather have that conversation somewhere more interactive than a mailing list thread. One thing I did want to address though — when people ask for an API, I don't think they mean "slap something on top of the existing servers as fast as possible, I want to tinker with your data." I think the larger ask is more about having a stable, purpose-built layer the community can build real integrations on — data portability for contributors, partnerships with other apps and organizations, reducing AW's own feature development burden over time, even conservation and academic use. There's also a bigger idea worth discussing around an open standard for whitewater data communication, but I'll save that for another time.

I also caught your interest in the AI-assisted moderation layer and improving the trip reporting experience — I'd love to share what I've been building.

Is there a Discord, Slack, or GitHub discussions board where the technical roadmap gets talked through? I'd love to find the right place to listen first and contribute without stepping on anyone's toes.

Thanks again for being open to the conversation.

— Ian
https://github.com/ikluhsman

[Tom Welander]

Before this discussion leaves this forum and goes to a purely tech-focused venue that's less attentive to broader considerations, I want to chime in and point out that it would be a disincentive for me to contribute to the river database if my donated content were given away for use elsewhere.  

I contribute content to the river database for the same reason I donate money to AW: to support AW's mission.  The river database  powers AW's work by elevating AW's standing in the paddling community and driving membership.  Please take care to ensure any use of the content furthers AW's vital work. --Tom W.

[Greg Akins]

I think that's a good point Tom, and my thoughts were A) Can AW Monetize their feeds and generate income to support the app and other efforts?  B) Is the API something that could be used by members in a more useful way?

[Greg Akins]

Hey Ian.. I emailed you separately, but a Discord, or Slack channel (Anything. but MS Teams Please!!!! :-D ) would be great.

On Tuesday, March 31, 2026 at 11:49:07 PM UTC-4 iankl...@gmail.com wrote:

[Ian K]

Tom and Greg — both good points, and I want to respond to each.

Tom — your concern is completely valid and I share it. AW has a privacy policy and terms of service that govern how contributed data can be used, and I don't think the development of more modern apps or features for the platform changes that. Any third-party tool or integration built on top of AW's data — including anything I'm building — has to operate within those same terms. That's not a loophole problem, I see it as a constraint that shapes the whole design. The data belongs to the community in spirit, and to AW in terms of stewardship and responsibility, and that must be protected.

Greg — I hear you on Discord or Slack. My only thought is that any separate channel is most useful if it stays connected to the people actively working on the platform. If there's already a roadmap discussion happening somewhere, I'd love to know where — I'd rather listen and contribute there than spin up something parallel.

My own interest is less in consuming AW's data independently and more in offering development capacity and architecture thinking that helps AW move faster — cost optimization, moderation tooling, the trip reporting UX, the streamflow UX, better data pipelines. Things Owen mentioned as actual pain points.

On the broader question of building independent river databases, I've come to the conclusion that it's not the right path. There is enough public data out there to seed a new database, but it will never have the depth or accuracy of decades of community input that AW has collected. I tried doing something similar using AI, but AI is only as good as the data it's given — left to find its own sources it hallucinates, conflates, and produces content no paddler should trust their safety to. Especially when it comes to rapid descriptions, reach descriptions, and flow range calculations. The only approach that worked for me is Retrieval Augmented Generation — where AI is given verified source data and reasons over that, rather than going looking for it on its own. For these reasons a contribution pipeline back to AW makes more sense to me than an extraction pipeline away from it.

I think some of this conversation belongs right here in this forum. The StreamTeam is the exact community that has both the domain knowledge and the motivation to shape what AW builds next.

— Ian

[Greg Akins]

> Greg — I hear you on Discord or Slack. My only thought is that any separate channel is most useful if it stays connected to the people actively working on the platform.
> If there's already a roadmap discussion
> happening somewhere, I'd love to know where — I'd rather listen and contribute there than spin up something parallel.

Totally agree Ian.. I would much rather reuse and enhance than recreate. 

[Paul Martzen]

I am encouraged by this discussion, especially by Owen's participation.  It is very nice to get direct feedback from one of the AW programmers.  I really hope we figure out ways to take good advantage of the many skill sets of our members.

--
You received this message because you are subscribed to the Google Groups "American Whitewater StreamTeam Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to american-whitewater-stre...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/american-whitewater-streamteam-forum/8f36dae0-fce7-462f-be38-cd769165038en%40googlegroups.com.