Skip to main content
Verified against 76c1f85Markdown

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.

You will
  • Know which guides apply to you, in order
  • Know what PlayerPal provides and what you build
  • Pass the go-live checklist with PlayerPal
You need
  • A signed agreement with PlayerPal
  • A technical contact who can receive credentials securely
For
Operators and game providers
Before you start

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.

  1. PlayerPal registers you

    PlayerPal registers your organisation as an operator and issues your party ID (pp_opr_…), partner credentials and scopes.

  2. Sign your first request

    Set up HMAC signing or OAuth and make one round trip. See Authentication and the Quickstart.

  3. Build the link flow

    Let players connect their account to PlayerPal and receive the aliases you send data for. See Link players.

  4. Send daily fact batches

    Deliver pseudonymous daily facts that feed your KPIs. See Send fact batches.

  5. Send activity, where agreed

    If your agreement covers it, deliver settled-round activity from an outbox for Points. See Send activity.

  6. Reconcile link state

    Handle player link notices and refresh alias status when you display link state. See Player link notices.

  7. Read your KPIs (optional)

    Pull your own KPIs for a date range. See KPI API.

  8. Go live

    Work through the go-live checklist with PlayerPal, then switch on production traffic.

What PlayerPal provides vs what you build​

Available
PlayerPal providesYou 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
  1. Credentials. Production credentials issued with exactly the scopes you need, stored in a secret manager, never in client-side code.
  2. Signing. Your HMAC signer reproduces the test vectors in Authentication and your servers keep accurate time (within 300 seconds).
  3. Linking. A test player can link and unlink, and your platform shows the correct state after each.
  4. No synchronous dependency. Login, game launch, wagering, settlement and payouts work with PlayerPal blocked at your network edge.
  5. Outbox. Activity is written in the same transaction as settlement, delivered in batches with a stable batch_id, and retried with backoff until accepted.
  6. Idempotency. Resending a batch returns the original receipt (replayed: true on fact ingest).
  7. Receipts. You monitor records_rejected and alert on rejections such as player_ref_unknown or currency_unsupported.
  8. Currency. Amounts are sent in EUR. Other currencies are not accepted yet.
  9. Reconciliation. You refresh alias status when displaying link state, not per wager.
Checkpoint

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.