From nothing to a
working integration.

Email us this

This is step one for everybody, so it's at the top rather than buried at the bottom. Paste it, fill in what applies, and we can usually create everything in one pass instead of three rounds of email. Send it to support@thegoodgame.com.

Organization name:        e.g. Riverside Sports
Primary contact + email:  who we send the organization ID to

Products we want:         registration & checkout / clearance / staffing
Way for each:             hosted / embedded-SDK / API
Checkout mode:            single-camp (default) / multi-camp (enable Multi-Camp Cart)
Domains we'll embed on:   e.g. www.riversidesports.com, camps.riversidesports.com

Branding:                 logo file, display name, the word you use for events
                          ("camps", "clinics", "sessions"), Meta Pixel ID if any

Clearance requirements:   which waivers, forms and documents each event must collect,
                          and how strictly each policy must be accepted
                          (informational / checkbox / drawn signature)

Webhook URL:              https://… (must answer 2xx within 15 seconds)
Scopes needed:            e.g. jobs:write, coaches:read, offers:write
Staging as well?          say yes — and ask for a staging organization AND a staging
                          event, or your first request 404s for boring reasons

Not sure which products or which way? Ways to integrate explains the three shapes, and Example integrations shows four businesses picking different mixes — find the one that looks like yours and copy it.

1. Email us and get your organization ID

   Send the block above. You get back a UUID, and we set your branding on your org record at the same time.

   The organization ID is not a secret and grants nothing on its own — it's a view filter. It's safe in client-side code, in a URL, and in your public HTML.

2. Ask us to enable checkout on the events you're selling

   An event needs a checkout configuration before it can take a registration. Without one the drawer opens and says registration isn't open — the single most common "why doesn't this work", and not a code problem.

   Choose your checkout mode: single-camp checkout is the default (Multi-Camp Cart OFF). For several camps from your organization in one cart, one checkout and one charge, ask your TGG contact to turn Multi-Camp Cart ON for your organization in TGG admin. This is separate from enabling checkout on each event: it is not a per-event setting or a code flag. Preview both options.

3. Drop in the loader and mark your buttons

   Two lines, and that's the entire embedded integration. See the checkout drawer for the JavaScript API, or hosted storefront if you'd rather just link to us and write no code at all.

   HTML Copy

   <script src="https://my-v2.thegoodgame.com/embed.js" defer></script>
   <button data-tgg-checkout data-event-id="{event_id}">Register Now</button>

   The example above opens checkout directly for one camp. When Multi-Camp Cart is enabled, the existing loader also shows the cart widget without a partner deploy. Use the Add to cart buttons and cart API for your custom camp cards, and preview cart styling for colors, placement and labels. Widget styling does not turn the checkout mode on or off.

Test on staging first by swapping the loader to staging.my-v2.thegoodgame.com/embed.js with a staging event ID — see Environments — then walk the go-live checklist before your first real registration.

Your first calls

Once you have an organization ID, this is your entire read surface for building a catalogue. No key, no headers, no signing — these endpoints are unauthenticated because they only return published, public event data.

# 1. Your organization's events, for a listing page.
curl "{API_BASE_URL}/api/v1/organizations/{organization_id}/events?size=5"

# 2. One event in full — schedule, venue, pricing, requirements, FAQs.
curl "{API_BASE_URL}/api/v1/events/{event_id}"

# 3. Live pricing and availability — the same bootstrap our own checkout reads,
#    so your page can't advertise a session the drawer will refuse.
curl "{API_BASE_URL}/api/v1/ec/events/{event_id}/checkout-config"

Every field, plus two response-shape gotchas worth knowing before you write your parser, is in the API section.

1. We issue your API key

   You can't mint your own. It's shown to you exactly once at creation and stored only as a SHA-256 hash, so if you lose it we can't recover it — only replace it. Details in API keys in detail.

2. Build against staging

   Staging is a separate database: your production organization ID, event IDs and keys do not exist there. Ask for a staging organization and at least one staging event when you ask for the key.

3. Register your webhook URL

   Send us an HTTPS endpoint; we generate your signing secret and can fire a test delivery at it, so you can prove your verifier works before a real event depends on it. See Registering a webhook — the test payload has a shape that catches people out.

4. We verify your sandbox and promote you to live

   We confirm four things, then mark you live. Sandbox & promotion covers what that does and, more importantly, what it doesn't.

API keys in detail

Worth reading before you write your secret-management code — two of these will surprise you.

curl "{API_BASE_URL}/api/v1/partner/jobs" \
  -H "Authorization: Bearer tgg_pk_live_xxxxxxxxxxxxxxxxxxxxxxxx"

# or, if a bearer header is awkward in your stack:
curl "{API_BASE_URL}/api/v1/partner/jobs" \
  -H "X-API-Key: tgg_pk_live_xxxxxxxxxxxxxxxxxxxxxxxx"

Registering a webhook

For staffing. Signing, verification code and the retry ladder are in Reference → Webhooks; this is just the setup sequence.

1. Send us an HTTPS endpoint

   It needs to answer any 2xx within 15 seconds. Do the real work asynchronously — acknowledge first, process after, or you'll trip retries you didn't need.

2. We generate your signing secret

   You don't choose it. Note that if no webhook URL is configured, events are silently skipped rather than queued — so an unset URL looks exactly like "nothing happened".

3. Ask us to fire a test delivery

   Cheapest proof that your endpoint, TLS and signature check all work. Two gotchas: it arrives as offer.accepted (there is no distinct test type), and its body is { "test": true, "message": "…", "timestamp": "…" } — no offerId. Check data.test before you dereference an offer payload.

4. Confirm you verified the signature, not just the status code

   A test that returns 200 from a handler that never checked the signature has proven nothing. Verify against the raw request body — parsing and re-serialising the JSON changes the bytes, and the HMAC will not match.

Sandbox & promotion

Your partner organization moves through three stages, and we track four concrete items to get you from one end to the other.

The four items we watch

Environments

Two environments, staging and production. They share no data — organizations, events, keys and bookings all exist independently in each, so ask for staging copies of anything you need to test against. Base URLs are in Reference → Base URLs; staging is the same host with a staging. prefix. Staging runs Stripe in test mode: use test cards, never a real one.

The embed loader derives everything from its own src, so switching environments in an embedded integration is one URL swap: staging.my-v2…/embed.js instead of my-v2…/embed.js. Don't mix them — a staging loader with a production event ID simply won't find the event.

Go-live checklist

Worth walking before your first real registration, not after it. The last two items only apply if you're on the Partner API track.