PAM IntegrationIntegration checklist

Integration checklist

This page is the one to hand to a PAM engineering team. It states who does what, in what order, how to test, and how to go live — so the integration lands without back-and-forth.

Roles: who does what

The integration is a two-sided setup. Most configuration is on the operator side (in PlaylogiQ); the PAM side is a straightforward HTTP sender.

Operator (PlaylogiQ side) — you

  1. Create the brand the PAM will feed (Settings → Brands), if it doesn’t exist.
  2. Issue a brand-pinned API key with the Ingestion only access level (Settings → Integrations → New API key). Copy the plq_… value once and hand it to the PAM over a secure channel.
  3. Configure the mapping for that brand (Settings → Integrations → PAM mapping) once you know the PAM’s event names and payload shape — see Mapping engine. Use the live tester with real sample payloads from the PAM.
  4. Verify events land correctly (dashboard Players/Analytics + the mapping page’s ingestion log).

PAM (integrator) — them

  1. Receive the base URL, the plq_… key, and (optionally) the agreed event names from the operator.
  2. Implement the sender: POST /api/v1/events with the x-api-key header, pushing events in real time (or micro-batched), with an event_id per event for idempotent retries. See Event ingestion API.
  3. Send sample payloads for each event type to the operator early, so the operator can build and test the mapping against real data.
  4. Handle responses: retry 5xx/429 (honour Retry-After), fix 4xx, and monitor unknown_event_types in responses.

The PAM does not need to know PlaylogiQ’s canonical model. It sends its own shapes; the operator maps them. The only hard requirements on the PAM are a stable player_id, a consistent event_type string per event kind, and an event_id for idempotency.

What the PAM must provide to the operator

To build the mapping, the operator needs from the PAM:

  • The list of event types the PAM will send (its own names).
  • A sample raw payload for each event type (real JSON).
  • Which payload fields carry: amount and its unit (major units or cents), currency, payment method, and player identity fields (email, name, country, …) on registration.
  • The player identifier the PAM will use as player_id (and confirmation it’s stable and unique per player within the brand).
  • Expected volume (events/second peak) so limits can be confirmed.

Recommended sequence

Operator: create brand ──► issue ingest key ──► send key to PAM
PAM: build sender ──► send SAMPLE payloads (per event type) to operator
Operator: build mapping in the tester using those samples ──► save
PAM: send test events to the real endpoint (a test/staging brand)
Operator: verify in dashboard + ingestion log ──► sign off
Both: switch traffic to the production brand/key ──► monitor

Environments & testing

  • The API is self-hosted, so the operator provides the exact base URL for each environment (e.g. https://crm-api.logiqdesk.com/api/v1).
  • There is no shared public sandbox. To test safely, the operator creates a dedicated test brand and issues a test key pinned to it, so test traffic never touches production data. Point the PAM’s non-prod environment at that key.
  • The operator validates any mapping in the live tester before enabling it — pasting the PAM’s real sample payloads shows the exact canonical output with no live traffic.
  • A ready-made smoke test (infra/smoke-test.sh) sends three events (a deposit, an idempotent re-send, and an unknown type) and checks the responses — a quick end-to-end confidence check against a test brand: 
    BASE=https://crm-api.<host>/api/v1 KEY=plq_your_key bash infra/smoke-test.sh

Definition of done

  • Ingest key issued, brand-pinned, events:write only.
  • Mapping configured and validated in the tester for every event type.
  • PAM sends every event with a stable player_id and an event_id.
  • Amounts, currency, and payment method map to canonical fields (verify a deposit shows correct revenue in Analytics).
  • Registration events populate player identity (email/name/country).
  • Retries + 429/Retry-After handled on the PAM side.
  • No unexpected unknown_event_types in responses.
  • Verified end-to-end on a test brand, then switched to production.

Stability & support

  • The API is versioned under /api/v1; breaking changes would ship under a new version, not by mutating v1.
  • The canonical event set may gain types over time (additive, non-breaking).
  • Coordinate the base URL, keys, and any volume-limit changes with the operator.

See also: Authentication · Event ingestion API · Mapping engine · Recipes & scenarios · Canonical event catalog.

OverviewAuthentication & API keys