Volleyball Elite Academy development update

Volleyball Elite Academy Corsizio Two-Way Integration — Design + PoC Corsizio Two-Way Integration — Design + PoC Volleyball Elite Academy — Development Update • May 13, 2026 --- title: Corsizio two-way integration — design + PoC --- Corsizio Two-Way Integration — Design + PoC What & Why Today Corsizio is the source of truth for event registration and payment, and our app pulls a copy of events + attendees every 4 hours. The board still wants Corsizio to handle checkout while the native registration wizard is finished, but every other surface (browsing, scheduling, communication, attendance, reports) should live in elitevolleyball.training. To get there we need to close two gaps in the integration: 1. Outbound: When an admin creates a session/event in our app, the matching event should appear in Corsizio without anyone copy-pasting. 2. Browse → Pay → Show up: Parents and athletes find the session they want on elitevolleyball.training, get handed off to the right Corsizio checkout, pay, and see the registration in our app within seconds. Before we build any of that, we need a written design that pins down exactly what Corsizio's API supports, what fields map between the two systems, and the failure modes (Corsizio is down, an admin edits an event after it's been pushed, a registrant exists in Corsizio but not in our database, etc.). That design is the deliverable here. Done looks like A short written design doc, committed at , that covers: - The exact Corsizio REST endpoints we will call for create/update/cancel of an event, and confirmation (with a real test call) that our API key has permission to use them. - A field-by-field mapping table: ↔ Corsizio event, including how our model (multi-date sessions) maps to Corsizio's date model, and how (WHOLE_EVENT / PER_DATE / PER_GROUP) translates. - A sequence diagram for the parent flow: Browse on our site → click Register → land on the right Corsizio checkout URL (with prefill if Corsizio supports it) → pay → webhook (or fast poll) brings it back → row appears in . - A decision on real-time updates: webhook subscription if Corsizio offers one, or a faster poll cadence (e.g. 5 minutes) if it doesn't, with the fallback documented. - Conflict-resolution rules for double-edits: if our app is the editor of record after creation, Corsizio edits made by hand should either be detected and overwritten, or surfaced to an admin in the existing Command Center tab. - A list of the new env vars / secrets required and any new permissions the Corsizio account owner has to grant. - Open questions for the board to confirm before build (e.g. "do you want our app to publish ticket prices, or keep that in Corsizio?"). A read-only proof of concept committed under (gated behind and SuperAdmin only) that, given an : - Builds the Corsizio create-event payload from our event row and prints it (no actual write). - Generates the parent-facing checkout deep-link URL the way the real button would, and renders it on a small page so we can click through and confirm the handoff lands on the right Corsizio page. - Calls against the matching Corsizio event (if exists) and shows the diff between our row and Corsizio's row in a simple table — proves we can detect drift before we build the real two-way sync. A short note added to under "Architecture decisions" describing which system owns which fields after the change ships. Out of scope Actually creating, updating, or deleting events in Corsizio from production code (PoC only — no real writes). Activating the native registration wizard ( / ). The board still wants Corsizio to handle checkout for now; we are only making the handoff cleaner. Replacing Stripe in the Academy Store. This work only touches the registration / event flow. Backfilling historical Corsizio events that were never linked. Building the production webhook receiver — the spec will define the route shape but the actual receiver lands in a follow-up task once the design is approved. Steps 1. Audit the Corsizio API. Read the public Corsizio REST docs end-to-end and record exactly which endpoints exist for creating, editing, cancelling events and for listing/subscribing to webhooks. Make one real test call against each candidate endpoint with our existing API key (in a throwaway test event) to confirm permissions and response shape. Capture every response in the design doc. 2. Map the data models. Sit our + + schema next to the Corsizio event + attendee schema and produce the field mapping table. Flag every field that has no clean equivalent and propose a rule (drop, default, prompt admin). 3. Design the parent handoff. Decide whether the Register button is a plain external link to the Corsizio checkout, an embedded iframe, or a server-side redirect that records intent first. Document the chosen flow and the prefill parameters Corsizio accepts (email, name) so returning users don't retype. 4. Decide real-time vs poll. Confirm whether Corsizio offers webhooks. If yes, draft the webhook route shape (path, signature verification, retry/idempotency strategy). If no, propose a 5-minute incremental poll using a cursor and document the trade-off. 5. Conflict + failure model. Write down the rules for: Corsizio is unreachable when an admin saves an event in our app (queue + retry), an event is edited in both places between syncs, a registrant pays in Corsizio but our match fails (today's auto-invite path stays — confirm in writing), and an event is cancelled on either side. 6. Build the read-only PoC. Implement the SuperAdmin-only page and route as described in "Done looks like". The PoC must not write to Corsizio. 7. Review with the board. Surface the open questions list at the top of the design doc so the board can answer them in one pass. Update the doc with their answers before any production build task is opened. Relevant files - - - - - - - - - Volleyball Elite Academy Reply to this email — we read every reply. You received this because you have an account with Volleyball Elite Academy. elitevolleyball.training