mark/vibn-frontend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
vibn-frontend/prd-template/open-source-and-api-references.md

6.6 KiB
Raw Permalink Blame History

Open-Source and API References for CampMatch + CampReg

Version: 0.1
Date: 2026-06-01

1. Purpose

This document collects useful reference products, APIs, and open-source projects that can inform CampMatch + CampReg product design.

These are not recommended as direct forks unless reviewed technically and legally. They are references for workflows, architecture, data models, feature expectations, and integration strategy.

2. Camp Management API References

2.1 CampMinder API

CampMinder publicly positions its API as a way to connect camp data with external tools including marketing platforms, Salesforce, Zapier, Google Sheets, dashboards, and accounting/reporting workflows.

Useful lessons for CampReg:

  • API-driven data syncing is valuable to camps.
  • Marketing integration is a major API use case.
  • Status changes should sync to outreach tools.
  • Financial data and staff/session data matter.
  • API support can be a services-led product, but CampReg can differentiate by making API access more self-serve.

References:

2.2 CampSite API

CampSite publicly documents REST API support for multiple camp domains.

Supported public areas include:

  • Families
  • Campers
  • Staff
  • Groups
  • Guests
  • Donors
  • Medical
  • Advanced reports
  • Financial transactions
  • Enrollment
  • Custom fields
  • Bunking boards
  • Bunking assignments
  • Transportation

Useful lessons for CampReg:

  • A serious camp API needs broad operational coverage.
  • Enrollment, financial, medical, bunking, and transportation are important data domains.
  • CampReg should add webhooks so external systems do not need to poll.
  • API docs should be accessible through a developer portal.

References:

2.3 ACTIVE Network Activity API

ACTIVE’s public Activity API exposes searchable public activity data including youth camps, but it is read-only.

Useful lessons for CampMatch:

  • Marketplace/search data can be modeled as public activity assets.
  • Public discovery APIs are distinct from operational provider APIs.
  • Read-only APIs support distribution but not provider operations.

Reference:

3. Open-Source References

3.1 eCamp v3

Type: Camp planning software
Relevant to: Camp planning, activity scheduling, responsive planning, printable plans
Not relevant to: Registration/payments as core system

Useful lessons:

  • Camp-specific planning workflows matter.
  • Responsive/mobile planning matters.
  • Printable camp plans remain important in the real world.
  • Activity planning can become a future CampReg module.

References:

3.2 Hi.Events

Type: Open-source event ticketing and management platform
Relevant to: Registration, ticketing, checkout, analytics, add-ons, webhooks, self-hosting

Useful lessons:

  • Event/session sales can be modeled cleanly.
  • Promo codes, product add-ons, offline payments, invoicing, and exports are useful patterns.
  • Webhooks are important for ecosystem integrations.
  • Self-hosted/event infrastructure offers useful deployment and developer-experience references.

References:

3.3 Attendize

Type: Open-source event registration/ticketing platform
Relevant to: Checkout, custom questions, attendee management, messaging, QR check-in, affiliate tracking

Useful lessons:

  • Custom questions during checkout map to CampReg registration forms.
  • QR/browser-based check-in concepts are useful for staff mobile workflows.
  • Messaging by attendee/ticket type maps to provider session messaging.
  • Affiliate/source tracking maps to CampMatch attribution.

Reference:

3.4 Youth/Student Attendance Projects

There are smaller open-source attendance/student projects that may provide lightweight ideas for rosters, attendance, and check-in. These should be inspected selectively, but CampReg should not rely on them for core architecture because camp requirements around parents, payments, child safety, pickup authorization, and provider operations are more complex.

4. Competitor Feature References

4.1 Campium

Relevant features observed:

  • Registration and forms
  • Billing and payments
  • Attendance
  • Medication tracking
  • Communication
  • Parent portal
  • Mobile app references
  • Reporting and analytics
  • Canteen/store
  • Staff scheduling

Useful lessons:

  • Camp management buyers expect broad operational coverage.
  • Medication tracking and parent portal are serious buying factors.
  • Canteen/store and mobile app can become advanced differentiators.
  • Analytics such as year-over-year registration and revenue comparisons are valuable.

Reference:

5. Product Design Implications

CampMatch + CampReg should adopt the best ideas from the reference landscape:

From CampMinder:

  • API-connected marketing and data automation

From CampSite:

  • Broad operational REST API coverage

From ACTIVE:

  • Public activity/discovery data model

From eCamp:

  • Camp planning and schedule orientation

From Hi.Events:

  • Modern event/ticketing checkout and webhooks

From Attendize:

  • Custom questions, messaging, QR check-in, affiliate/source tracking

From Campium:

  • Full camp management feature breadth

6. CampReg Differentiation

CampReg should not simply clone incumbent camp software.

Differentiators:

  • Direct CampMatch marketplace demand
  • Kid-centered matching
  • Parent-first mobile registration
  • Provider operating system
  • API-first architecture
  • Webhooks from the beginning
  • VibnAI growth automation
  • Missinglettr campaign execution
  • Marketplace attribution
  • Underfilled session automation
  • Local SEO and content generation

7. Legal and Licensing Caution

Open-source references must be reviewed before reuse.

Important considerations:

  • AGPL projects may impose obligations if code is reused or hosted as network software.
  • Some projects may be useful for learning but not safe to copy.
  • Product concepts are safer to reference than source code.
  • Legal review is required before incorporating any third-party code.
Reference in New Issue View Git Blame Copy Permalink