Is there documentation for api.scouting.org? I started a postman collection based on what I saw in the browser requests:
Collection Web View | Postman
And started on a TypeScript client:
But obviously it’d be better to work off API documentation vs reverse engineering.
No. No plans to release it either. The BSA, through intermediaries, has been very very clear.
@DanKlco - best advice is to stop what you are doing and get rid of what you have thus far.
I took it down. That’s really disappointing to hear. It’s hard to understand why the BSA / people seem so hostile to those trying to make things better.
@DanKlco BSA is correctly concerned about PII is the base answer and contacting youth.
Keep in mind that many of these decisions likely trace back to risk management somewhere along the line. Folks in risk management tend to be conservative where the choice between “do something different” and “do not do something different” is offered.
I understand the concern, but I hope that whomever is working on these tools understands that security by obscurity isn’t a reliable means of security, especially when they’re already sending the information down to the browsers.
More or less, what the BSA is doing right now is putting a sign out in the yard saying “please don’t steal the safe under the bed in the front bedroom”
They have only addressed the fact they won’t open the api. They haven’t talked one way or the other about their current security approach.
Hi Dan, is your postman collection still available? I’d like to use it too.
I keep seeing the same refrain whenever the topic of an API comes up: “PII concerns,” “risk management,” or “contacting youth.” While security is obviously important, these answers miss the point.
Modern systems across industries—from banking to healthcare—expose APIs safely every day using hardened, audited, and highly secure architectures. The technology to protect sensitive data at “bank-level security” is not speculative—it’s routine. Today, with AI-driven monitoring, anomaly detection, and automated policy enforcement, making a system secure is easier than ever. There really isn’t an excuse anymore for saying APIs can’t be safely opened.
If the hesitation here is that an open API would automatically be insecure, that’s a red flag. It suggests the current architecture may be legacy or mainframe-based, relying on “security through obscurity” rather than true modern protections. If you think the old legacy and mainframe systems are secure, think again. For every student we have in America, China has that many honors students. There are countless highly skilled actors itching for opportunities to exploit weaknesses, and Scouting America is a prime target. To be clear, I have nothing against China—it’s simply where I found compelling data that highlights the scale and sophistication of global cyber threats.
If that’s the case, families’ data is already at risk. Sensitive information sitting in systems that can’t be safely integrated is far more concerning than an API that can be safely secured. And let’s be blunt—if these legacy systems are compromised, it won’t just be an internal problem. Don’t be surprised when it becomes the next big scandal for Scouting.
Another point that needs to be said: the dismissive attitude of moderators toward these requests is discouraging. Scouters who raise these questions aren’t being reckless; they’re trying to push for tools that could strengthen the program. Shutting down those conversations with a wave of the hand doesn’t just stifle innovation—it hurts the community. People leave those exchanges feeling dismissed instead of heard. That weakens trust and engagement at a time when Scouting America needs both.
Even the so-called “new” systems currently being rolled out show us that we are still a long way from having a strong, modern digital platform. That doesn’t mean progress is impossible—quite the opposite. But it does mean that real modernization, including secure APIs, is not optional if Scouting America wants to meet families’ expectations in the 21st century.
With the increasing complexity of daily life—and with the chaos our government has thrown us into—we need tools that make Scouting simpler, not harder. A properly designed API could help families automatically sync calendars, track rank advancement in real time, integrate medical or consent forms securely, streamline communication between leaders and parents, and enable councils to see accurate participation data instantly. These aren’t “nice to haves”; they are basic capabilities expected in modern organizations.
Scouting America needs to ask itself: does it want to keep operating like it’s 1999, or does it want to remain relevant in a modern digital environment where secure integration is expected? APIs aren’t just a convenience—they’re the standard for secure, auditable, and efficient data exchange.
If we want tools that help families, leaders, and councils succeed, the organization needs to open its APIs and do so with the same rigor and seriousness that financial institutions apply. Anything less is kicking the can down the road while putting trust in outdated systems.
I made an account here specifically to post this because I believe the issue is that important. I’ve tried to write this as objectively as possible without regard to emotion—because the issues here aren’t about personal preference, they’re about fundamental technology realities that can’t be ignored. I also say this from experience: before my academic and government work, I spent years in customer-facing roles at Best Buy and Geek Squad, which gave me a deep appreciation for user needs and perspectives. Academically, I hold both my B.S. in Computer Science and my Ph.D. (ABD) in Cyberspace Engineering from Louisiana Tech University. Professionally, I’ve worked with the government and currently serve as an Adversarial Cloud Developer with Cloud Range. My perspective comes directly from designing, testing, and securing systems in some of the most demanding environments, while never losing sight of what end-users actually need. The patterns I see in Scouting America’s approach are the same ones that put critical organizations at risk when they resist modernization.
Finally, since moderator tone and approach directly impact whether people feel heard, what is the official procedure for requesting a new moderator when the current ones are not constructively engaging with the community?
I also want to acknowledge that AI assisted me in structuring this post. I agree with everything written here, and I have personally vetted the following sources that support the claims I’ve made.
Best,
Christopher M. Smith
Cubmaster, Pack 1703
Houston, TX
Sources
Legacy and Mainframe Risks
Financial Times – “Legacy IT systems: the hidden threat to financial stability” (ft.com)
The Financial Brand – “Banking Legacy Systems are Under Siege” (thefinancialbrand.com)
Quinnox – “Legacy Mainframe Modernization” (quinnox.com)
Info-Tech Research Group – “Legacy Systems in Financial Services” (infotech.com)
AI-Driven Security & Modernization
TechRadar – “Generative AI: A Game Changer for Mainframe Modernization” (techradar.com)
TechRadar – “Harnessing AI’s Potential on the Mainframe” (techradar.com)
Adaptigent – “Mainframe Automation in 2025” (adaptigent.com)
StackSync – “The Hidden Risk: How Unmodernized Legacy Systems Threaten AI Security” (stacksync.com)
APIs & Security Consolidation
China’s Cyber Threat Landscape
Cyber Magazine – “China’s Cyber Espionage Surges 150%” (cybermagazine.com)
Wikipedia – “Chinese Espionage in the United States” (en.wikipedia.org)
Wired – “How China’s Hackers Became Elite Cyber Spies” (wired.com)
Fundamentally, the folks who make the decisions are not on these discussion groups and don’t accept this kind of feedback via the SUAC volunteers. If you want to convince national to change their position on this, you’ll have to work through your council professionals to make the argument on your behalf. You could even “ghost-write” the message for them to present, if they’re willing.
This is a possible avenue, and I’ll keep it in mind—thank you for suggesting it.
That said, I don’t prefer to ghostwrite. I’d rather stand behind my own words, show up directly, and make the case in person if that’s what it takes.
Also, do you have an answer to my question?
I get that, and feel the same way myself. At the same time, keep in mind there’s currently no generally accessible direct-to-national scouter support process, and even here there’s nobody to carry the message. SUAC has already conveyed the message that national has said “no” to opening up the API. All of the major changes that have (even potential) policy implications have to go up through the professional staff at the council level. This is particularly true, I suspect, where national has already specifically said “no” to a request.
I suppose you could write a physical letter. National still has a public mailing address, although I couldn’t begin to tell you who specifically to address if you did, not what would be a convincing argument even if you reached the right person.
Which one? About the mods? I don’t even know how they’re selected, so I couldn’t tell you how to raise concerns. I’m just a unit ASM who’s been around long enough with SB & SB+ that I try to help point folks at solutions (or bugs) I know about from watching the groups. I’m far from officialdom here. :^)
Since you mentioned that Scouting America has been “very clear” on this, could you point me to any official statement or documentation from Scouting America that says so? Having something concrete would be very helpful in understanding their position and knowing who to contact.
Thanks for taking the time to explain all of this—I appreciate your perspective and the background you’ve shared.
I understand that you’re “far from officialdom,” and that helps me place your comments in context. What I’m really looking for are official statements or documentation from Scouting America itself. Having those would go a long way in clarifying their position and ensuring that any next steps are based on their own published guidance.
Just to add a bit more context—the data I’m referring to already lives in scouting.org, which is the same system this site ties into. That means the endpoints and structures clearly exist. The real question isn’t whether they’re there—it’s who within Scouting America can speak to them officially. Someone here should know the right contact, and that’s what I’m trying to identify. We’re ultimately just trying to correct a broken policy.
@ChristopherSmith34- what is the broken policy that needs to be fixed?
Simple answer is National has no plans to open API to Volunteers or Third Party Providers.
Thanks for asking, Stephen! Quick question first: are you speaking in any official capacity for Scouting America, or could you point me to someone who is? Having an official contact will help move this forward constructively. Also, did you have a chance to read my earlier message? I thought I was pretty clear about what’s broken, but let me lay it out again here for clarity.
Also—nice TARDIS avatar. Did you like the newest season? I loved it; Matt Smith is still my favorite Doctor.
To your question: I’m glad you asked. When I say “broken policy,” I’m referring to gaps that flow from Scouting America’s own Privacy Policy (effective Feb 12, 2020) at Privacy Policy | Scouting America . Reading it line-by-line, this is what needs to be fixed or clarified:
Specific policy gaps to fix:
Unclear technical controls
No adoption of recognized security standards
Medical data without a HIPAA stance
Location data collection is explicit
Vendor and council governance
No breach-notification commitment
Retention and deletion are vague
Do Not Track (DNT) ignored
APIs mentioned, governance isn’t
What I’m asking for:
Publish a controls baseline mapped to NIST or ISO, including encryption at rest, key management, MFA, RBAC, logging/monitoring, patch SLAs, and regular third-party pen tests.
Clarify HIPAA applicability for medical data (or publish equivalent safeguards and BAAs if applicable).
Adopt and disclose vendor/council security requirements (e.g., SOC 2 Type II or ISO 27001) and require attestations.
Publish a breach-notification policy with timelines and channels.
Provide a retention/deletion schedule by data category.
Offer granular privacy controls (or acknowledge/implement Global Privacy Control equivalents) and document handling of location data.
Publish API security documentation (scopes, review, least-privilege, audit, revocation).
And importantly: open API access for developers. Units, councils, or vetted third parties can choose to hold/process this data if they go through their own audit process. This can be automated, controlled, and logged. There’s no technical reason this can’t be done anymore.
If you’re not official (totally fine!), could you point me to someone who is and can address these points directly? I’m aiming for accuracy and a path to resolution.
© 2026 Boy Scouts of America - All Rights Reserved
