WagerStreet · GSWallet API v1.0

PWallet API Atlas

Every operation published at pwallet.wagerstreet.net/docs — 407 operations across 303 paths, every GET and HEAD probed live against the read-only key on 2026-09-04 (92 readable · 28 blocked · 251 writes). 9 operations are new since the original 2026-08-17 catalog and 61 changed access — they are called out below. Tick the ones worth building on — the basket turns your picks into an access request. Regenerated by make-pwallet-atlas-page.mjs from the same catalog the back-office gateways route by.

Calling the API — send x-api-key-source: db

Every request needs three headers, not two. x-api-key and x-partner-id identify the key; the third, x-api-key-source: db, tells the API to resolve the key's permissions from the database instead of the legacy baked-in set. Confirmed by the WagerStreet developers on 2026-09-03: the grants they make for this key live in that DB row and are managed from PAM, so they only apply when the header is present — the same endpoint can answer 403 without it and 200 with it. With the header, new grants made in PAM take effect without a key change.

curl "https://pwallet.wagerstreet.net/api/customers/exclusions" \ -H "x-api-key: $KEY" \ -H "x-partner-id: $PARTNER" \ -H "x-api-key-source: db"

The buckets below reflect this header: the whole catalog was re-probed with x-api-key-source: db on 2026-09-03, and six operations flipped from 403 to readable versus the header-less 2026-09-01 run — customers/exclusions, operator/exclusions, bonus, bonus/{bonusId}, products/categories and game-catalog-config. Grants made in PAM apply to the DB permission set, so a 403 below clears as soon as the grant lands — no key change needed.

0 picked

Access request

Send this to the WagerStreet side. It lists exactly what the key must reach, split by what already works and what needs granting.