Sportsbook API Integration 2026: Operator and Developer Guide to Platform, Webhooks, and Affiliate Postbacks

A sportsbook is an integration project before it is a product. The thing the customer experiences as one app is, on the operator side, a federation of APIs: a platform and player-account-management (PAM) layer that owns the wallet and the player record, an odds and trading feed that prices the markets, a bet-placement and settlement engine, payment and KYC services, and - the part most engineering plans underscope - the affiliate tracking layer that has to know, at the moment of registration and at the moment of every settled bet, which partner sent the player. Get the affiliate wiring wrong and the commercial team is paying revenue share against numbers nobody can reconcile.

This guide is the developer-and-operator map of that integration surface for 2026. It walks the major API categories (platform/PAM, odds feed, wallet/player, webhooks and event streams), the cross-cutting concerns every integration has to get right (authentication, idempotency, rate limits, sandbox), and then the affiliate-attribution integration in detail: server-to-server (S2S) postback, conversion API, deep links, and bet-level event hooks. It is deliberately distinct from the odds-feed and data-feed vendor buyer guides, which compare odds providers; this is the platform-API and affiliate-integration developer guide. It does not promote any bet. It is operator-side and engineering-side analysis.

The sportsbook integration surface: five API layers that must agree

Five distinct interfaces, not one API, make up a modern sportsbook integration, and they all have to agree on identity, timing, and money. The platform/PAM layer owns the player record and wallet. The odds feed pushes prices and results. The bet engine accepts stakes and emits settlement events. The payments and KYC services move and verify funds. The affiliate tracking layer maps every one of those events back to the partner who acquired the player. The integration fails the day two of these layers disagree about who a player is or when a bet settled, which is why a shared player identifier and a shared event clock are the two most load-bearing design decisions in the whole project.

Most operators in 2026 buy the platform and trading layers from a turnkey or PAM vendor and integrate the rest. That makes the operator an API consumer for the core book and an API provider for the affiliate and partner ecosystem at the same time. The odds and results side of that surface is its own discipline, covered in the sports betting data feed and odds API providers guide; this guide assumes you have chosen a feed and focuses on how the platform, event, and affiliate APIs wire together.

Platform and PAM APIs: the player record and wallet

The PAM API is the system of record for player identity, wallet balance, bonus state, and responsible-gambling limits, and every other integration defers to it. When a player registers, the PAM mints the canonical player ID that the bet engine, the payments service, and the affiliate layer all reference. When a bet is placed or a bonus is granted, the wallet API is the single authority on the balance. A clean integration treats the PAM player ID as the join key across the entire stack and never invents a second identity scheme in the affiliate layer, because the moment two systems carry different IDs for the same human, attribution and reconciliation break.

Typical platform/PAM endpoints fall into four groups: player lifecycle (create, read, update, suspend, self-exclude), wallet (get balance, credit, debit, list transactions), bet/ticket (place, cash-out, void, settle, query), and bonus (grant, list, forfeit). Most vendors expose these as versioned REST resources returning JSON. The affiliate layer subscribes to the lifecycle and bet events rather than calling these endpoints on a schedule, so the affiliate platform is reacting to the same authoritative events the book itself records, not a delayed copy.

Wallet and player APIs feed cohort attribution

The wallet and player APIs are also where affiliate cohort quality becomes visible. A registration event carries the click ID; a first-deposit event carries the deposit amount; each settled-bet event carries stake, payout, and product category. When those flow into the affiliate platform keyed on the PAM player ID, the operator can break affiliate-attributed revenue down by cohort and product rather than reporting a single blended number. Track360 ingests these events and resolves them against the partner who delivered the original click, which is why the real-time reporting layer can show per-affiliate net gaming revenue keyed to the same player IDs the PAM uses.

Authentication: OAuth 2.0, API keys, and signed payloads

Three patterns cover almost all authentication in a sportsbook stack, and the correct one depends on the direction of trust. Machine-to-machine REST calls between your services and the platform typically use OAuth 2.0 client-credentials grant as defined in IETF RFC 6749, where your service exchanges a client ID and secret for a short-lived bearer token and presents it on each call. Simpler feed and postback integrations use a static API key, usually combined with an IP allowlist so a leaked key alone is not enough to call the endpoint. Inbound webhooks and postbacks should be authenticated by verifying an HMAC signature over the raw payload using a shared secret, so the consumer can prove the message actually came from the book and was not tampered with in transit.

The operator-side rule of thumb is to never rely on a single secret in a single place. Bearer tokens should be short-lived and refreshed; API keys should be scoped to the narrowest set of endpoints they need and rotated on a schedule; webhook and postback secrets should be per-partner so one compromised affiliate integration cannot forge events for another. Treat the affiliate postback token as a credential, not as a tracking parameter, and rotate it the same way you rotate a database password.

Webhooks and event streams: idempotency, retries, and ordering

Idempotency is the single property that makes webhooks safe, and webhooks are the backbone of a sportsbook integration. Because networks fail and platforms retry, your endpoint will receive the same bet-settled event more than once, and if processing it twice credits an affiliate twice or settles a wallet twice, the integration is broken regardless of how clean the happy path looks. The fix is to require every event to carry a unique event ID, persist the IDs you have already processed, and make the handler a no-op on a repeat. An idempotent consumer turns at-least-once delivery, which is all any retrying producer can promise, into effectively exactly-once processing.

Three other event-stream concerns deserve explicit handling. Retries: the producer will back off and retry failed deliveries, so your endpoint must return a 2xx only after the event is durably stored, not after it is merely received. Ordering: events can arrive out of order (a settlement before its placement under retry), so the consumer should key on the player and bet IDs and tolerate gaps rather than assume strict sequence. Replay: a good platform lets you replay a window of events after an outage, which is how you backfill missed affiliate commissions without manual reconciliation. The affiliate platform must support the same replay window so the two sides stay in sync.

Affiliate tracking integration: S2S postback, conversion API, and deep links

Server-to-server tracking is the foundation of affiliate attribution in a regulated sportsbook, not browser cookies, because cookie-based attribution does not survive app installs, cross-device journeys, or modern browser privacy controls. The mechanism is a deep link that carries a click ID from the affiliate into the registration flow, a server-side store that binds that click ID to the new player account, and an S2S postback the book fires back to the affiliate platform on each meaningful event. Done correctly, attribution holds whether the player registers on web, installs the app, or completes the journey on a different device a week later.

S2S postback: server-side event handoff

An S2S (server-to-server) postback is an outbound HTTP call the sportsbook makes to the affiliate platform when a tracked event occurs, carrying the click ID, the event type (registration, first deposit, settled bet), and the event values (deposit amount, stake, NGR contribution). Because it is fired server-side from the book to the affiliate platform, it is invisible to the browser, immune to ad blockers and cookie loss, and auditable on both sides. The postback URL is configured per program and should be treated as a credentialed endpoint: a token in the URL plus an IP allowlist, retried on failure, and deduplicated by event ID on the receiving end so a retried postback does not double-count a conversion.

Conversion API: server-side handoff to ad platforms

A conversion API is the same server-to-server idea pointed at advertising platforms rather than affiliates. Instead of relying on a browser pixel to tell Meta, Google, or TikTok that a registration or deposit happened, the operator sends the conversion server-side from its own backend, with hashed identifiers for matching. For a sportsbook this matters twice over: pixel-based conversions are heavily degraded by privacy controls, and gambling advertising sits under stricter platform and regulatory review, so a clean, server-side conversion signal with proper consent handling is both more accurate and easier to govern. The affiliate platform is the natural place to own this, because it already holds the click-to-conversion mapping the conversion API needs.

Deep links and bet-level event hooks

Deep links solve the inbound half of the problem: when a partner sends a player, the click ID has to survive the jump from the affiliate's content into the operator's web flow or native app and land on the registration call. Bet-level event hooks solve the ongoing half: every settled bet emits an event the affiliate platform consumes to accrue commission against the right partner, with product category preserved so the operator can later distinguish straight-bet from parlay traffic. Track360's integrations layer is built around exactly this chain - deep-link issuance, click-ID persistence, S2S postback ingestion, and bet-level event mapping - so the affiliate attribution does not depend on the browser at any step. The commission logic behind it is covered in the sports betting affiliate programs guide.

Rate limits, idempotency keys, and resilience

A rate limit is a contract, not an obstacle, and a sportsbook integration that ignores it will be throttled at the worst possible moment, which is peak NFL Sunday or a major soccer fixture. Platform and odds APIs typically publish a request budget per second or per minute and return an HTTP 429 with a Retry-After header when you exceed it. The correct client respects Retry-After, backs off exponentially with jitter, and - more importantly - avoids the load entirely by consuming push events instead of polling. Where a write must be retried after a 429 or a timeout, attach an idempotency key (a client-generated unique value per logical operation) so the server can recognize the retry and return the original result rather than performing the operation twice.

Resilience in this stack is mostly about assuming every dependency will be briefly unavailable and designing so a blip does not corrupt money or attribution. Queue outbound postbacks and ad-platform conversions so a downstream outage delays rather than drops them. Make settlement and commission handlers idempotent so replays are safe. Persist raw inbound events before processing so you can reprocess after a bug fix. The same idempotency-key and replay discipline that protects the wallet protects affiliate commissions, because both are ultimately ledgers that must never double-count.

Sportsbook integration build checklist

Seven ordered steps take an engineering team from a standing start to a sportsbook integration that is ready before the affiliate program goes live with real commercial terms. The order is not optional, because each step depends on the identity and event decisions made in the ones before it.

1. Lock the identity model first. Decide that the PAM player ID is the single join key across platform, payments, KYC, and affiliate layers, and forbid any system from inventing a second identifier for the same player. Everything downstream depends on this.
2. Stand up authentication per direction. OAuth 2.0 client credentials for your outbound REST calls, scoped and rotated API keys for feeds, and HMAC-signed payloads with per-partner secrets for inbound webhooks and postbacks.
3. Subscribe to events, do not poll. Wire your consumer to the platform's webhook stream for registration, deposit, KYC, bet-placed, and bet-settled events, returning 2xx only after durable storage.
4. Make every consumer idempotent. Require a unique event ID on each event, persist processed IDs, and no-op on repeats so retries and replays cannot double-settle a wallet or double-pay an affiliate.
5. Build the affiliate chain end to end. Issue deep links that carry a click ID, bind that click ID to the PAM player ID at registration, fire S2S postbacks on registration/FTD/settled-bet, and preserve product category on each bet event.
6. Add the conversion API for paid channels. Send server-side conversions to ad platforms with hashed identifiers and proper consent so attribution survives browser privacy controls and meets advertising-review requirements.
7. Certify everything in sandbox, then handle rate limits and replay. Run the full event chain against simulated events, verify idempotency and 429 back-off behavior, confirm you can replay a missed window, and only then mint production credentials.

Two compliance touchpoints bracket the whole build. On the marketing side, server-side conversion and affiliate tracking has to operate within the American Gaming Association responsible marketing code for sports wagering, which governs how operators and their affiliates may advertise. On the technical side, UK-licensed operators must build to the UK Gambling Commission remote technical standards, which set requirements for data integrity, event logging, and player-account handling that directly shape how the platform and event APIs must behave. The odds and results side, meanwhile, is governed by your data vendor's own contract - see The Odds API documentation for a representative example of how a sports-data API is structured.

Where the affiliate layer fits in the wider operator stack

The affiliate integration is the part of the sportsbook API surface most likely to be treated as an afterthought and most expensive to retrofit. Because it has to bind a click that happened in someone else's content to a player record in the PAM and then to every settled bet that player ever places, it touches identity, events, and money at once. An operator running an iGaming affiliate program that wires this correctly from day one - PAM player ID as the join key, S2S postback on a credentialed endpoint, idempotent settlement consumers, deep links and a conversion API for acquisition - gets affiliate revenue reporting that reconciles to the penny against the book's own ledger. An operator that bolts attribution on afterward spends the first season arguing with partners about numbers.

That is the practical reason to design the integration around the affiliate and event layers, not just the trading layer. The trading and odds APIs make the book a book; the platform, event, and affiliate APIs make it an auditable commercial operation where every dollar of partner-driven revenue can be traced from the click that produced it to the bet that settled it. Both halves are engineering work, and both belong in the same integration plan from the first sprint.