# For game providers

PlayerPal lets the rounds your games already settle earn Points for linked
players, and gives your studio analytics on how those players play, without
handling personal data or sitting in the game loop. You report facts about
settled rounds; PlayerPal does the loyalty calculation.

The labels mean: **Available** (built and tested in the platform), **In
development** (being built; behaviour may change) and **Planned** (designed,
not built yet).

## What you get

| Capability | What it means for you | Status |
|---|---|---|
| Activity from game rounds | Settled rounds sent in batches earn Points for linked players | [Available] |
| Studio analytics | Rounds, bets, wins and share of turnover for the players reached through your integrations | [Available] |
| Cohort analytics | Distinct-Account counts across all your integrations, with small groups suppressed | [Available] |
| KPI API and comparisons | Own KPIs, anonymous comparison with the network, and peer benchmarks among providers | [Available] |
| PlayerPal widget | A PlayerPal panel you can show inside your game experience | [In development] |
| Provider launch sessions | A pattern for receiving launch context from the operator safely | [In development] |
| Provider portal | Browser workspace for your studio analytics | [In development] |

## Aliases scoped to one casino

[Available]

A provider works with many operators, so PlayerPal gives you a separate Alias
(`pp_plr_prv_…`) for each provider-operator integration. The same player at
two casinos reaches you as two unrelated Aliases. You cannot join a player
across casinos through PlayerPal, and no other party can join your Aliases
with theirs.

- Aliases are random and contain no personal data, account IDs or timestamps.
- Your integration, not a field in the payload, decides which casino an event
  belongs to.
- An Alias issued to someone else gets the same response as one that does not
  exist.

## Off the game path

[Available]

PlayerPal is never called at launch, bet or settlement. The operator places
your provider Alias in its existing launch payload. Your backend writes
eligible rounds to its own outbox and sends them to PlayerPal in batches
after settlement, retrying until they are accepted. If PlayerPal is
unavailable, games keep running and winnings are paid as normal.

## Launch sessions and the widget

The operator creates a short-lived launch session through your own backend;
PlayerPal is not involved. Launch context is passed in a single-use request
body, never in the game URL. Your page receives only your integration's
Alias and a coarse connection status. Points balances, the ledger and the
player's private PlayerPal ID stay on PlayerPal surfaces.

You load the PlayerPal widget as an exact, versioned build from PlayerPal,
checked with Subresource Integrity. You do not rebuild or redistribute it,
and a widget failure never blocks play.

| Part | Status |
|---|---|
| Versioned widget builds served with integrity hashes | [Available] |
| Launch session pattern | [In development] |
| Provider-led linking from inside your experience | [Available] |

## Studio and cohort analytics

[Available]

Studio analytics count distinct Accounts across all of your integrations, so
a player who plays your games at two casinos is counted once. Windows with
fewer Accounts than the minimum are suppressed. You can also look up figures
for a single Alias that was issued to you; the response contains numbers
only, such as rounds and turnover with you and elsewhere.

The KPI API adds your own KPIs, a comparison with the rest of the network and
benchmarks against other providers, all behind the same anonymity rules. See
[Privacy thresholds](../analytics/privacy-thresholds.mdx).

## Integration status

| Part | Status |
|---|---|
| Activity batches and large uploads, idempotent | [Available] |
| Per-partner credentials for activity batches | [In development] |
| Daily game and catalogue facts through fact ingest | [Available] |
| Studio analytics and KPI API with OAuth or signed requests | [Available] |

## Related

  - [Send activity](../developers/sending-activity.mdx): 
    Batch settled rounds and handle retries.
  
  - [Widget](../developers/widget.mdx): 
    Load the PlayerPal widget in your game experience.
  
  - [Availability](../developers/availability.mdx): 
    Why play never waits for PlayerPal.
  
  - [KPI API](../developers/kpi-api.mdx): 
    Studio KPIs, comparisons and benchmarks.
  
  - [Fact ingest](../developers/fact-ingest.mdx): 
    Daily game and catalogue facts.
  
  - [Privacy](../trust/privacy.mdx): 
    What PlayerPal holds and who can see it.