Registration & Checkout

We handle these no matter which option you pick

Your options

Three ways in. If you'd rather see them as complete paths than as a menu, skip to the examples — or see all three side by side on Ways to integrate.

Storefront & booking Live

Server-rendered, crawlable pages on our domain, scoped to your organization. Link to them from your navigation and you have a working registration business.

These render without JavaScript and are indexable — but the SEO credit lands on our domain. If you want it on yours, use event-card fragments or the event API instead.

Customer Portal — your team's console Live

The operator side, and the part partners most often don't realise they're getting. Your own staff sign in at app-v2.thegoodgame.com and run the whole business from there. It comes with every integration option — you never build admin screens.

Everything your team creates here is what the public API and the checkout drawer then expose to your customers — one source of truth, two audiences. See it on Ways to integrate.

Org-Scoped Parent Portal Live

Checkout is the transaction. The portal is everything after it — and that's where most of the support burden actually lives. A parent who bought from you gets a self-service account, branded as your organization, that only ever shows them your events.

Add it to your account menu as "Manage my registrations" and you're done. No hosting, no build step, no data sync. It pairs with either the hosted storefront or the embedded drawer.

What a parent can do

Getting a buyer from checkout into the portal

The checkout and the portal are both served from {WEB_BASE_URL} — the same origin, no matter whose site the checkout was embedded on. So the account a buyer creates while checking out is their portal account. There's no user record to sync, no SSO handshake to implement, no identifier to map, and you never hold a credential.

Under the hood a login on either surface sets an HttpOnly refresh cookie (tgg_rt), and the other surface silently redeems it on boot via POST /auth/session — both halves are live in production, so a buyer who signed in during checkout normally lands in the portal already authenticated.

Best-effort, not guaranteed. The cookie is third-party from your page, so browsers that partition storage may withhold it until the drawer is granted Storage Access. Then the parent signs in once at the org sign-in screen. Treat a sign-in prompt as a normal outcome, not a bug — the deep links work either way.

# The portal home — put this in your account menu
{WEB_BASE_URL}/org/{organization_id}/manage

# Straight to one booking — use after a checkout completes
{WEB_BASE_URL}/org/{organization_id}/manage/bookings/{booking_id}

# Behind auth, surviving the sign-in bounce
{WEB_BASE_URL}/org/{organization_id}/manage/signin?redirect=%2Forg%2F{organization_id}%2Fmanage%2Fbookings

To get {booking_id} at the moment of purchase, listen for booking-complete on the drawer — see the JavaScript API. Branding and feature toggles are set on your organization record.

Memberships Live

Recurring revenue alongside one-off bookings. A membership is a subscription your organization publishes; families buy it once and it then covers the events you say it covers. Billing, renewals and cancellation all run on our side.

Where each side manages it

• Your team creates and publishes memberships in the Customer Portal.
• Families see and cancel theirs in the Org-Scoped Parent Portal. The page is hidden entirely for organizations that don't publish any, so it never shows an empty screen.

Memberships are configured in the portal rather than over the API today — there's no public membership endpoint yet. Tell us if you need one.

Checkout drawer Live

One script tag and one button attribute puts our entire registration and payment flow on your site. It opens as a full-viewport overlay on top of your existing page, so you don't need a dedicated event-detail page — trigger it from a listing, a hero CTA, a card, anywhere.

Because everything inside the drawer is served and processed by us, you stay out of payment handling entirely — card data never touches your page or your servers.

What's inside the drawer

Install

<!-- once, before </body> -->
<script src="https://my-v2.thegoodgame.com/embed.js" defer></script>

<!-- auto-wired on DOMContentLoaded -->
<button data-tgg-checkout data-event-id="{event_id}">
  Register Now
</button>

<button onclick="TGGCheckout.open({ eventId: '{event_id}' })">
  Register Now
</button>

Drawer JavaScript API Live

The loader exposes window.TGGCheckout.

data-org / open({ org }) is accepted and reserved for multi-org hosts, but does not yet change behavior — pass eventId only.

// embed.js is deferred, so wait for load before touching TGGCheckout.
window.addEventListener('load', function () {
  TGGCheckout.on('booking-complete', function (e) {
    dataLayer.push({ event: 'registration_complete', booking_id: e.bookingId });
  });

  TGGCheckout.on('close', function () {
    console.log('checkout dismissed');
  });

  // Optional: pre-warm on an event page so the first open is instant.
  TGGCheckout.init({ eventId: '{event_id}' });
});

How the embed behaves on your page

Useful when you're debugging z-index, CSP, or analytics on a host page.

Event-card fragments Live

The most interesting option if you care about search: we render just the event-card grid, with no page chrome, and you inject it server-side into your own template. Google crawls your URL and sees fully-rendered listings.

1. Fetch it server-side when your page renders
   cURL Copy

   curl "{WEB_BASE_URL}/s/org/{organization_id}/events/fragment?city=Fort%20Worth&sport=Tennis&size=12"

2. Extract and inject the grid

   The response is an HTML document; the piece you want is the single element marked data-tgg-fragment="events". It carries data-tgg-total, data-tgg-page and data-tgg-size so you can render your own pagination.

   HTML (returned) Copy

   <div data-tgg-fragment="events" data-tgg-total="192" data-tgg-page="0" data-tgg-size="12">
     <div class="grid …">
       <!-- one rendered event card per event -->
     </div>
   </div>

3. Style it and wire the buttons

   Scope your CSS to [data-tgg-fragment], then add data-tgg-checkout data-event-id="…" to the Register buttons so they open the drawer.

Fragment filters (this is the SSR fragment vocabulary, not the JSON API's — see Event list for that one): city, market, zipCode, sport, activityId, eventType, q, minPriceCents, maxPriceCents, minAge, maxAge, genderPolicy, tag, dateFrom, dateTo, sort, page, size. Status is checked against an allowlist, so ?status= cannot reach drafts or cancelled events; ?sort=past and ?sort=all widen it to include completed. Visibility is a separate axis — the fragment forces public-only, unlike the JSON list above.

Chrome-free iframe pages Live

If you'd rather embed whole pages than build them, the server-rendered routes have an /embed variant with our site chrome stripped, sized to drop into an iframe on your layout.

An iframe is opaque to crawlers. If search matters, prefer fragments, which put the markup in your own document.

Event list Live

Every published event across every coach in your organization. Note the default includes events marked private — pass isPrivate=false for only the publicly-listed ones.

curl "{API_BASE_URL}/api/v1/organizations/{organization_id}/events?size=20&sportName=Tennis"

{
  "data": {
    "total": "20",          // string — parse it before you paginate
    "data": [ /* events */ ] // note: data.data, not data
  },
  "timestamp": "2026-08-13T16:44:41.360Z"
}

Event detail Live

Schedule occurrences, venue, the pricing plan with every purchase option, participation requirements, registration features, organizer, activity, FAQs, and the vanity slug. Accepts a UUID or a legacy numeric id.

{
  "data": {
    "event": {
      "id": "9f8e7d6c-0000-4111-a222-333344445555",
      "title": "Summer Tennis Camp — Session I",
      "eventType": "Camp",
      "status": "published",
      "registrationModel": "per_event",
      "timeZone": "America/Chicago",
      "pricingCurrency": "USD",
      "occurrences": [
        { "date": "2026-08-03", "startTime": "14:00:00", "endTime": "21:00:00", "status": "scheduled" }
      ],
      "venue": {
        "name": "Riverside Varsity Courts",
        "address": { "line1": "123 Main Street", "city": "Fort Worth", "region": "TX", "postalCode": "76109" }
      },
      "pricingPlan": {
        "purchaseOptions": [
          {
            "id": "dddd1111-2222-3333-4444-555566667777",
            "name": "Full Day Ticket",
            "priceCents": 64500,
            "priceCentsWithFees": 70950,
            "audienceType": "participant",
            "capacity": 50,
            "registrationCount": 12
          }
        ]
      },
      "participationRequirements": { "minAge": 5, "maxAge": 18, "genderPolicy": "any" },
      "registrationFeatures": { "capacityLimit": 100, "capacityMode": "hard_cap", "registrationOpen": true },
      "slug": "summercamp"
    }
  },
  "timestamp": "2026-08-06T17:57:02.785Z"
}

Companion reads

description fields contain sanitized HTML — render as rich text or strip tags. Every monetary field is an integer in cents.

Pricing & availability Live

The bootstrap the checkout drawer itself uses. Read it so your own page can't advertise a session the drawer will refuse.

Booking writes Planned

There is no server-to-server booking or payment endpoint today. This is the one real limit on an API-only registration integration, so it's called out rather than buried.

The parent-facing /ec/* endpoints the drawer calls are authenticated as the parent, not as a partner — they aren't a server-to-server surface and aren't documented as one.