On this page
A useful summer camp registration form collects one guardian contact, the selected session, and only the camper details staff need to plan attendance. Keep one guardian record separate from one registration per child and session; this makes siblings easy to register without copying family contact details or collecting a broad medical history.
Download the sample CSV · Download the form field specification
Summer camp registration form template
AI-generated editorial concept; not a screenshot of a deployed app.
| Section | Fields | Why it belongs |
|---|---|---|
| Guardian | Name; email; preferred contact method | Send confirmation and schedule changes to the responsible adult. |
| Session | Session name or ID; start and end dates; location | Tie every registration to one published camp session. |
| Camper | First name or roster label; age band; optional accessibility or participation note | Give staff enough information for the roster. Do not request full date of birth unless the program has a documented need. |
| Consent | Guardian acknowledgment of participation terms; optional photo permission as a separate yes/no choice | Keep permissions clear and let families answer optional requests independently. |
| Fee | Fee shown for the selected session; payment status returned by the payment flow | Make the charge and registration status visible without storing card details in the form. |
Ask the guardian to select a session before showing its dates, location, capacity status, and fee. Require one camper entry for each child. If a family registers siblings, create separate registrations linked to the same guardian. Show a review screen with the selected session and total before submission.
A minimal sample CSV might look like this. The rows are synthetic and use roster labels rather than children’s names.
guardian_key,guardian_name,guardian_email,session_id,session_name,camper_label,age_band,terms_accepted,photo_permission,registration_status
G001,Alex Example,[email protected],SUM-01,Week 1,Child A,8-10,true,false,submitted
G001,Alex Example,[email protected],SUM-01,Week 1,Child B,6-7,true,true,submitted
The guardian key links sibling registrations. In the actual app, show the family’s email only to the guardian and authorized staff; do not put it in a public roster. Ask about allergies or medical needs only in a separate, access-restricted process designed for that purpose. A general registration template should not collect diagnoses, medications, insurance details, or emergency medical records.
Model sessions and registrations separately
The following is a proposed data model for an app, not a built-in Atoms camp template:
| Table | Suggested fields | Ownership |
|---|---|---|
camp_sessions |
id, name, starts_at, ends_at, location, capacity, fee, status |
Staff manage; public page shows only active session details. |
guardians |
id, auth_user_id, name, email, contact_preference |
Guardian can read and edit their own contact record; staff can manage it. |
registrations |
id, guardian_id, session_id, camper_label, age_band, terms_version, photo_permission, status, created_at |
Guardian sees registrations linked to their account; staff see assigned sessions. |
payments |
id, registration_id, amount, currency, provider_reference, status |
Store a provider reference and status, never card number or security code. |
Keep capacity changes and payment status explicit. A submitted registration can be pending_payment, confirmed, waitlisted, cancelled, or refunded; define which transition reserves a seat and how a failed payment releases it. For siblings, each registration has its own session and status even when the guardian is shared. In Supabase, enable row-level security on every exposed table and set grants as well as row policies; the database checks both before a request can access a row. Supabase Row Level Security guide
If you build the app with Atoms, choose Atoms Cloud or connect one Supabase project. Atoms’ setup guide says an Atoms project can connect to one Supabase project at a time and cannot use Supabase and Atoms Cloud together; connecting a database alone does not add the form or persistence behavior. Build the feature, enter harmless test data, refresh the app, and confirm the same record appears in the intended table. Atoms’ Supabase guide
Keep payment optional and scoped
A camp can publish the form without online payment. Add a deposit or full-fee checkout only after the operator sets refund, cancellation, waitlist, and seat-reservation rules. For Stripe Checkout, confirm payment and fulfil the registration from verified webhook events; Stripe warns that a customer may pay without reaching the success page and says fulfilment must be safe to run more than once for the same Checkout Session. Stripe fulfilment guide
Keep payment secrets server-side and save only the registration ID, amount, currency, provider reference, and verified status. A redirect can show the family a receipt page, but the server-side event controls the payment transition.
Build and check the registration flow
Start with one session, two synthetic guardian accounts, and two registrations for the first guardian. Test this sequence: open the session page, submit one child, submit a sibling, refresh, edit a permitted field, and read both rows again. Sign in as the second guardian and verify that the first family’s registrations cannot be opened or edited. Then sign in as staff and confirm access is limited to the assigned session.
Also test a full session, a closed session, a duplicate submission, and a declined payment if payment is enabled. Confirm that the capacity count follows the chosen reservation rule and that the family sees a clear next step. A sibling checkout may cover several registrations. Link each paid line to its registration and confirm the reserved seats together; if one seat hold has expired, send that line to review or refund rather than silently overbooking.
You can also start from Atoms’ spreadsheet-to-web-app guide if session information already lives in a sheet.
Atoms build prompt
Build a summer camp registration app using Supabase.
Use tables camp_sessions, guardians, registrations, payments.
Keep guardian contact separate from camper registration rows.
A guardian account can read and edit only its own guardian row.
A guardian can read and edit only registrations linked to that account.
Staff can manage sessions and registrations for assigned sessions.
Public visitors can read active session name, dates, location, fee, and open capacity only.
Never expose guardian email or private notes on public pages.
Collect a roster label and age band for each camper.
Do not collect diagnoses, medications, insurance, or general medical records.
Require guardian acceptance of a versioned terms statement.
Make photo permission a separate optional yes/no field.
Allow a guardian to register multiple campers for one session.
Give each camper and session pairing its own registration and status.
Define statuses: submitted, pending_payment, confirmed, waitlisted, cancelled.
Reserve capacity only at the status transition agreed in the interface.
Check and reserve capacity in one server-side transaction.
Give submissions a unique request key and return the existing receipt on retry.
Release unpaid holds at expiry; route late payment success to review or refund.
Link every paid checkout line to its individual registration.
Start with payment disabled; show session fee and payment state clearly.
If enabled later, keep provider secrets server-side and save only a verified reference.
Use synthetic seed data for two guardians and three registrations.
Create a staff account assigned to one session and an unrelated guardian account.
Test registration creation, refresh, edit, and readback in Supabase.
Test that the second guardian cannot read or edit the first guardian's records.
Test staff access against assigned and unassigned sessions.
Test duplicate submit, full session, closed session, and waitlist behavior.
If payment is enabled, test pending, success, decline, duplicate event, and refund status.
Show the confirmation screen with session details and a family-specific registration receipt.
Copy the build brief and use it to create your version in Atoms.
