iGaming Platform API Integration Checklist 2026

7 categories of external system connect to an iGaming platform in production, and every one of them fails in the same predictable ways when the integration contract is left implicit. Missing idempotency keys produce double-counted deposits. Absent retry semantics produce silently dropped events. Undefined identifier ownership produces two systems that cannot be joined. Sandbox environments that do not mirror production produce a certification pass followed by a launch-week incident. This checklist is written for the engineer who has to sign off the integration rather than for the person who bought the platform, and it covers authentication, event delivery, identifiers, schemas, reliability, idempotency, latency, sandbox and certification, versioning, and the affiliate event contract that most integration specifications omit entirely.

• Authentication: OAuth 2.0 client credentials for server-to-server APIs, signed webhooks with HMAC and a shared secret, and mutual TLS where the counterparty supports it
• Event delivery: webhooks as the primary channel, polling reserved for reconciliation and backfill rather than as the main path
• Identifiers: the player identifier is minted once by the platform, the affiliate click identifier is persisted onto the player record at registration, and session identifiers are stable for the session lifetime
• Reliability: at-least-once delivery, exponential backoff with jitter, a bounded retry window, a dead-letter queue, and a replay endpoint that is tested rather than assumed
• Idempotency: every mutating request and every financial event carries an idempotency key, and receivers deduplicate on it for a documented retention window
• Latency budgets are written per event class, from sub-second CRM triggers through to 24 hour warehouse batch loads, and measured end to end rather than at the sender
• Versioning: a stated scheme, a minimum deprecation notice, and a written definition of what counts as a breaking change, agreed before the first line of integration code

Scoping the Integration Surface

Operators must connect at least seven external systems to the platform before launch, and each connection has a different reliability requirement rather than a shared one. A CRM trigger that arrives four seconds late is a degraded experience. A deposit event that arrives four hours late is a financial reporting problem. A KYC status change that never arrives is a regulatory incident. Treating all integrations as one class of work, with one retry policy and one latency target, guarantees that the strictest requirement is either unmet or applied wastefully everywhere.

Platform architecture influences how much of this you control. Modular platform suites expose separate API surfaces per component, which lets an operator replace one module without renegotiating the whole stack, while single-API suites present one integration surface across casino, sportsbook, aggregation, and affiliate modules. Sportsbook-specific providers add their own feed and settlement semantics on top. Whichever architecture you inherit, write the integration surface down as a table with an owner, a delivery mechanism, and a latency budget per connection, because that document is what stops the launch-week argument about whose retry policy applies.

Authentication Patterns

Three authentication patterns cover practically every iGaming integration: OAuth 2.0 client credentials for outbound server-to-server API calls, HMAC-signed payloads for inbound webhooks, and mutual TLS where both parties can support certificate management. Static bearer tokens with no rotation policy remain common and should be treated as a finding rather than a design. The question to settle per connection is not which pattern is most secure in the abstract but which one both parties can operate correctly, including rotation, revocation, and the incident path when a secret leaks.

Webhook authentication deserves specific attention because it is where operators are most often exposed. An unsigned webhook endpoint accepting deposit or verification events is an unauthenticated write path into your financial and compliance data. Require a signature over the raw request body, a timestamp inside the signed payload, and rejection of requests outside a short clock-skew window to prevent replay. Verify the signature before parsing the body, keep the previous secret valid during rotation, and log verification failures as security events rather than as parse errors.

Event Webhooks Versus Polling

The standard pattern is webhooks for event delivery with polling reserved for reconciliation, and inverting it is the most common architectural error in operator integrations. Polling for player events at any practical interval either wastes capacity or introduces latency that makes real-time use cases impossible, and it scales with the number of consumers rather than with the number of events. Webhooks push each event once to each subscriber at the moment it happens, which is both cheaper and faster, at the cost of requiring the receiver to be always available.

Polling still has a job, and skipping it is equally an error. A scheduled reconciliation poll, typically hourly for financial events and daily for aggregate revenue facts, catches everything the webhook path lost to outages, deploys, and dead-lettered messages. Design it as a sequence or cursor-based query rather than a timestamp range, because timestamp ranges lose events written out of order and duplicate events at boundaries. The pair of mechanisms together, push for timeliness and pull for completeness, is what makes reconciliation between platform, warehouse, and affiliate platform converge rather than drift.

Player and Session Identifiers

Four identifiers must be defined before any integration work begins: the affiliate click identifier, the player identifier, the session identifier, and the transaction identifier. Ownership matters more than format. The platform mints the player identifier once and every other system references it, never mints its own. The affiliate platform mints the click identifier and the operator persists it onto the player record at registration, which is the single most important line of code in the entire acquisition data model, because if it is missing no downstream work recovers the link between marketing spend and revenue.

Session identifiers should be stable for the lifetime of a session and must never be used as a join key for anything financial. Transaction identifiers must be globally unique per system and carried through every downstream event that references the transaction, including reversals and adjustments. Where a player can hold accounts across multiple brands within a group, decide explicitly whether a group-level identity exists, because retrofitting one later requires reprocessing history and is the usual reason cross-brand lifetime value reporting is unavailable.

Deposit and NGR Event Schemas

Financial event schemas require six fields at minimum: event type, player identifier, amount, currency, UTC timestamp, and idempotency key. Amounts should be transmitted as integer minor units with an explicit currency code rather than as floating point values, because floating point rounding differences between systems produce reconciliation variances that are extremely expensive to diagnose after the fact. Timestamps should be ISO 8601 in UTC with no local time anywhere in the contract, and any event that can be reversed must carry both its own identifier and the identifier of the transaction it reverses.

NGR is not an event, it is a calculation, and treating it as an event is a category error that causes persistent disagreement between systems. What crosses the wire is the inputs: gross gaming revenue for the period, bonus cost, fee deductions, and adjustments, each at a defined grain with a defined period. The receiving system applies the agreed formula. If two systems both calculate NGR from different inputs, they will disagree, and the disagreement will surface as an affiliate dispute at the end of the month rather than as an alert at the time of divergence. Publish the formula and the deduction list in the integration specification alongside the schema.

Postback Reliability and Retry Semantics

Operators must design postback delivery for failure rather than for success, with at-least-once semantics, exponential backoff with jitter, a bounded retry window, and a dead-letter queue as the baseline. Networks partition, receivers deploy, and rate limits trigger, and a delivery design that assumes none of these happen will lose events in its first month of production. The receiving side must be idempotent precisely because the sending side retries, which is why the two decisions are made together rather than separately.

Retry policy should be explicit about which response codes trigger a retry and which do not. A 5xx response or a timeout is retryable. A 4xx response other than 408 and 429 is a permanent failure that should be dead-lettered immediately rather than retried for hours against an endpoint that will never accept the payload. Rate-limit responses should be honoured through the documented retry-after header rather than through the generic backoff schedule. Every dead-lettered event needs an operational path back into the system, which means a replay endpoint and a runbook, both tested before launch rather than written during the first incident.

Idempotency and Exactly-Once Accounting

Idempotency is the mechanism that converts at-least-once delivery into exactly-once accounting, and without it every retry is a potential double-counted deposit or duplicated commission accrual. The sender generates a stable key per logical event, not per HTTP attempt, and reuses that key across all retries of that event. The receiver stores keys it has processed and returns the original result for a repeat rather than reprocessing, for a retention window long enough to exceed the maximum retry window by a comfortable margin.

Two details are missed frequently enough to be worth stating. First, the idempotency key must be derived from the business event rather than from a random value generated at send time, because a random key regenerated on retry defeats the entire mechanism. Second, deduplication must be applied at the point where the side effect occurs, not at the API gateway, since a gateway-level cache typically has a shorter memory than the retry window and offers no protection against a replayed event from a dead-letter queue hours later. Test both by replaying a known event and asserting that financial totals do not move.

Latency Budgets Per Event Class

Latency budgets must be written per event class, from sub-second CRM triggers through to 24 hour warehouse batch loads, and they must be measured end to end rather than at the point of sending. A platform that emits an event within 50 milliseconds and a receiver that processes it 90 seconds later has a 90 second budget, not a fast one, and only end-to-end measurement reveals that. Instrument the event with an origin timestamp and record the processing timestamp at the receiver, then alert on the percentile rather than the mean, because tail latency is what breaks real-time use cases.

The Affiliate Event Contract

The affiliate platform requires five event classes at minimum: registration, qualifying deposit, verification status, revenue facts, and suppression, plus risk flags where clawback is contractual. This is the integration most often treated as an afterthought and it is the one with direct commercial consequences, because affiliate commission is calculated from these events and disputes over them consume affiliate management time every month. Server-to-server postbacks carry the events in real time; a scheduled API export in the reverse direction carries deal terms, qualification rules, and accrued commission back into the operator warehouse.

Commission logic is what makes the payload requirements non-negotiable. CPA deals need the qualifying deposit event with amount, currency, and timestamp, gated on verification status, so that qualification rules can be evaluated deterministically. RevShare deals need revenue facts as inputs, specifically GGR, bonus cost, and fee deductions, because NGR must be calculated from a single agreed formula rather than computed independently on both sides. Hybrid deals need both, and negative carryover requires the full period history rather than positive months only. Sending a computed NGR figure instead of its inputs is the most common cause of month-end reconciliation work between operators and affiliates.

Risk and suppression events close the loop. Multi-accounting, bonus abuse, and self-referral detected by the fraud, CRM, or verification layer are the evidential basis for CPA clawback and for reviewing an affiliate source, and they are only actionable if they reach the affiliate platform with the player identifier attached. Suppression events covering self-exclusion, consent withdrawal, and account closure must stop further crediting as well as further marketing. Where geo-targeting restrictions apply, the market must be present on the registration event so traffic from restricted jurisdictions is never credited, which matters for MGA, UKGC, GGL, and ADM licensees whose regulatory obligations extend to affiliate conduct. Player lifetime value reporting by source depends on the same feed, which is why this contract serves analytics as well as commission.

Sandbox, Certification, and Go-Live

Sandbox parity determines whether integration testing is meaningful or theatre, and the parity questions are specific rather than general. Does the sandbox emit the same event set as production, including the failure and reversal events that are rare in normal operation? Does it enforce the same authentication, rate limits, and payload validation? Can you trigger arbitrary scenarios on demand, including verification failure, deposit reversal, and self-exclusion, or only the happy path? A sandbox that only produces successful flows validates nothing that matters, since every serious production incident originates in the paths it cannot produce.

Certification requirements vary by market and by counterparty and should be scheduled as a dependency rather than discovered late. Regulated markets impose their own conformance steps, and sportsbook integrity obligations add data-sharing expectations for licensees in integrity monitoring arrangements. Plan a certification window with a defined re-test path, freeze the integration contract before entering it, and keep every conformance artefact, because regulators ask for evidence long after the engineers who produced it have moved on.

Versioning and Deprecation Policy

Three versioning commitments belong in every integration contract: a stated version scheme, a minimum deprecation notice period, and a written definition of what counts as a breaking change. Without the third, the first two are unenforceable, because a counterparty that considers adding a required field to be non-breaking will ship it without notice and break you anyway. Agree that removing or renaming a field, changing a type, changing an enumeration's meaning, tightening validation, and altering default behaviour are all breaking, and that additive optional fields are not.

Receivers should tolerate unknown fields and enumeration values rather than rejecting them, which converts a class of breaking changes into non-events. Ask every counterparty for their deprecation history rather than their policy statement, because a stated six month notice period means little from a vendor whose last three changes shipped with two weeks of warning.

Pre-Launch Test Plan

Nine test classes should pass before go-live, and the ones that catch real defects are the failure-path tests that teams under schedule pressure skip. Happy-path testing validates that the integration works when nothing goes wrong, which is not the condition it will spend its life in. Run the table below as a gate rather than as a checklist to be partially completed, and record the evidence, because the same evidence answers the audit question later.

A short execution sequence keeps the integration work ordered and prevents the common pattern where testing begins only after everything is built. Each step below produces an artefact that the next step depends on, so the order is not a preference.

1. Write the integration surface table first, listing every connected system with its owner, direction, delivery mechanism, and reliability class, and get it signed off by both engineering and compliance.
2. Agree identifier ownership and propagation before any code is written, including who mints the player identifier and where the affiliate click identifier is persisted at registration.
3. Publish the event schemas with required fields, minor-unit amounts, UTC timestamps, idempotency keys, and the NGR formula and deduction list stated explicitly.
4. Implement delivery with at-least-once semantics, an explicit retry policy per response class, a dead-letter queue, and a replay endpoint, then implement receiver-side deduplication.
5. Establish latency budgets per event class with end-to-end instrumentation and percentile-based alerting before load testing begins.
6. Run the full pre-launch test plan including every failure-path test, then freeze the contract, complete certification, and keep the conformance evidence.

Methodology & Inclusion Criteria

Checklist inclusion requires that an item is verifiable in testing, applicable across platform vendors rather than specific to one, and consequential enough that omitting it causes a production or commercial failure rather than an inconvenience. Items that meet those three tests appear above. The checklist is written from integration patterns that are common across iGaming platform suites, payment providers, and affiliate platforms, and it deliberately avoids vendor-specific endpoint names, because those change and the underlying requirements do not. Where a latency figure or retry window is given it is a recommended starting budget to be negotiated against your own architecture, not an industry standard.

Several areas are excluded on purpose. Game aggregation transaction protocols are excluded as a specialism with its own certification path. Payment scheme and card network requirements are excluded because the schemes rather than the platform set them. Regulator-specific technical reporting interfaces are excluded because they differ per market. Front-end and SDK integration is excluded as a separate discipline. None of this constitutes legal or compliance advice, and licence-specific technical obligations must be confirmed with your regulator and qualified counsel.

No vendor is ranked, scored, or recommended anywhere on this page, and platform architectures are described only where they change the integration approach. This page is authored by Track360, which supplies affiliate and partner-program infrastructure and therefore sits on the receiving end of the affiliate event contract described above; that section is written as a specification any affiliate platform should satisfy rather than as a description of one product. This checklist is reviewed quarterly and updated as integration patterns and regulatory expectations change. Engineers and vendors who can evidence a correction or an omission are invited to contact us, and amendments will be applied at the next review.

Frequently Asked Questions

Five questions cover the decisions engineering teams raise most: webhooks versus polling, idempotency design, what the affiliate platform needs, realistic latency targets, and how to judge a sandbox.