Onboard as a partner
This page is your integration path from a signed agreement to live traffic. PlayerPal provides your identity and credentials; you build a link flow, deliver data asynchronously and, if you are a game provider, optionally embed the widget. None of it sits in your login, launch, wagering or payout path.
There is no public sandbox yet and no self-service console. PlayerPal issues every credential and ID during onboarding, and arranges a test environment with test credentials for your integration. Contact PlayerPal to start.
Your path
Pick your role. Each track runs from contract to go-live; every step links to the guide that covers it.
- Operator
- Game provider
- PlayerPal registers you
PlayerPal registers your organisation as an operator and issues your party ID (
pp_opr_…), partner credentials and scopes. - Sign your first request
Set up HMAC signing or OAuth and make one round trip. See Authentication and the Quickstart.
- Build the link flow
Let players connect their account to PlayerPal and receive the aliases you send data for. See Link players.
- Send daily fact batches
Deliver pseudonymous daily facts that feed your KPIs. See Send fact batches.
- Send activity, where agreed
If your agreement covers it, deliver settled-round activity from an outbox for Points. See Send activity.
- Reconcile link state
Handle player link notices and refresh alias status when you display link state. See Player link notices.
- Read your KPIs (optional)
Pull your own KPIs for a date range. See KPI API.
- Go live
Work through the go-live checklist with PlayerPal, then switch on production traffic.
- PlayerPal registers you
PlayerPal registers your organisation as a game provider and issues your party ID (
pp_prv_…), an integration ID (pp_int_…) for each operator integration, partner credentials, scopes and the integration key. - Sign your first request
Set up HMAC signing or OAuth and make one round trip. See Authentication and the Quickstart.
- Build the link flow
Support the linking modes your operators use and receive provider aliases (
pp_plr_prv_…). See Link players. - Send activity from an outbox
Write settled rounds to a local outbox and deliver them in batches for Points. See Send activity and Design for availability.
- Send daily fact batches
Deliver pseudonymous daily gameplay facts that feed KPIs. See Send fact batches.
- Reconcile link state
Handle player link notices and refresh alias status when you display link state. See Player link notices.
- Add the widget and KPIs (optional)
- Go live
Work through the go-live checklist with PlayerPal, then switch on production traffic.
What PlayerPal provides vs what you build
Available| PlayerPal provides | You build |
|---|---|
Party ID. Your public ID: pp_opr_… for operators, pp_prv_… for game providers. Used as source_id in fact batches. | Link flow. Operators and game providers; required. Link players |
Integration ID. For game providers, the ID of each operator integration (pp_int_…). Sent as x-integration-id on activity and linking calls. | Activity delivery from an outbox. Game providers, and operators where agreed; required for Points. Send activity |
| Partner credentials. An HMAC key ID and secret, an OAuth client, or both. The HMAC secret is shown once. | Daily fact batches. Operators and game providers; required for KPIs. Send fact batches |
Scopes. ingest.write to send facts, kpis.read to read KPIs, studio.read for game provider studio analytics. | KPI reads. Operators and game providers; optional. KPI API |
| Integration key. The current key for activity and linking routes. Per-partner credentials for these routes are in development. | Widget. Game providers; optional. Widget |
| Test environment. Arranged with test credentials on request. | Alias status reconciliation. Operators and game providers; recommended. Player link notices |
You can hold up to two active HMAC keys. PlayerPal can rotate a key with a 24-hour overlap or revoke one immediately. Keep test and production credentials separate, and never reuse a key across environments.
Design every part so it fails open: if PlayerPal is unavailable, players keep playing. See Design for availability.
Go-live checklist
Available- Credentials. Production credentials issued with exactly the scopes you need, stored in a secret manager, never in client-side code.
- Signing. Your HMAC signer reproduces the test vectors in Authentication and your servers keep accurate time (within 300 seconds).
- Linking. A test player can link and unlink, and your platform shows the correct state after each.
- No synchronous dependency. Login, game launch, wagering, settlement and payouts work with PlayerPal blocked at your network edge.
- Outbox. Activity is written in the same transaction as settlement, delivered in batches with a stable
batch_id, and retried with backoff until accepted. - Idempotency. Resending a batch returns the original receipt (
replayed: trueon fact ingest). - Receipts. You monitor
records_rejectedand alert on rejections such asplayer_ref_unknownorcurrency_unsupported. - Currency. Amounts are sent in EUR. Other currencies are not accepted yet.
- Reconciliation. You refresh alias status when displaying link state, not per wager.
With PlayerPal blocked at your network edge, a test player can still log in, launch a game, play and be paid; when you unblock it, the queued batches deliver and their receipts show no unexpected rejections.