Partner onboarding

A practical checklist for integrators starting work on a Trybe integration: what to ask us for, what you'll receive back, and how to graduate from a sandbox build to a production rollout.

What you'll be issued

When an integration kicks off, you'll receive (typically by email) five pieces of information. Keep them somewhere you can find them again — every API call you make will reference at least the API key and the site ID.

If anything is missing from your kickoff email, ask for it before you start building. Reverse-engineering a Site ID from a UUID list is not a productive use of your time.

Base URLs

Both environments serve the same OpenAPI surface; switching base URL is the only change required to move a working integration from sandbox to live.

A typical build loop

1. Confirm credentials work: GET /token-info with the playground key returns the decoded JWT claims and a 200. If you see a 401, the bearer header is wrong; if you see a 200 with an unexpected sub, you have the wrong key.
2. Browse the reference at docs.try.be/endpoints for the resources you'll touch. Each operation page shows the exact request and response shapes plus copy-paste curl/JS/Python snippets.
3. Build against playground end-to-end. See Test cards for card numbers that exercise the happy-path, declines, and 3DS challenges in playground without moving real money. SMS sends are throttled to whitelisted numbers. You can break things confidently.
4. Verify the booking engine URL if your integration involves the consumer-side flow — the playground booking frame uses your test inventory so end-to-end smoke tests don't require backend stubs.
5. Ask for a production token when you're ready. See below.

Graduating to production

When the sandbox build is signed off and you're ready to point at live data:

1. Tell your Onboarding Manager you need a production key. Include the name of the site (or sites) you're integrating with, not just the playground tenant — the live site lives in a different organisation tree.
2. The site manager for that venue has to authorise the key issuance by email (a one-line "yes, this is approved" reply is enough). You'll need their email; if you don't know who they are, your Trybe contact can find them.
3. The production token comes back via a one-time-use link. Store it under a different env var (e.g. TRYBE_API_KEY_PROD vs TRYBE_API_KEY) so a misconfiguration can't cross-fire.
4. Swap the base URL to https://api.try.be and re-run your integration test suite. Wire format is identical — if something breaks here that worked in playground, it's almost always an ID-shaped problem (production IDs are different UUIDs from the sandbox ones).

Seeding the sandbox with realistic data

A common ask: "the playground tenant is empty, can I get realistic treatments / services / practitioners to test against?" Two paths:

• Read-only token against the production tenant so you can copy the catalogue across yourself via the SDK or curl. Ask for this explicitly; it requires the same site-manager approval as a production write key.
• A data export from the team — typically a CSV / JSON dump of the treatment catalogue, practitioners, and availability patterns, which you re-import via the playground admin UI.

No strong preference from our side — whichever is easier given how your build is structured.

What stays the same across both environments

• The OpenAPI spec — every operation, schema, parameter name and response shape is identical.
• Authentication — bearer token in the Authorization header.
• Error envelopes — same message / errors[] shape in both envs.
• Rate limits — see Rate limits.
• Webhooks — both environments deliver the same event types; you just register a separate listener per environment.

When to ask for help

If you're stuck on a single endpoint, paste the curl you're running and the response you got. Don't paraphrase — the wire output is what we'll triage from.