iGaming

iGaming Integration Guide

Integration guide for casino, sportsbook, and poker operators connecting player data, financial transactions, and gaming activity to Track360.

iGaming Integration Guide

Integration guide for casino, sportsbook, and poker operators connecting player data, financial transactions, and gaming activity to Track360.

This guide covers the entity schemas, authentication flow, sample payloads, and onboarding checklist needed to connect your igaming platform to Track360. All data is exchanged via REST API using JSON payloads over HTTPS.

Integration Patterns

iGaming integrations typically follow a push model where the operator platform sends customer registrations, deposit/withdrawal events, and daily gaming activity summaries to Track360 via REST API. The data flows through three primary entities: Customers (player accounts and attribution), Transactions (deposits, withdrawals, bonuses), and Gaming Activity (daily aggregated play data per game type). This enables Track360 to calculate RevShare commissions based on GGR or NGR, trigger CPA events on first-time deposits, detect fraudulent patterns, and deliver real-time reporting to affiliates.

Pull — Track360 Retrieves Your Data

Track360 periodically pulls data from your API or database

Track360

requests data

Your API / DB

returns data

Track360

You expose a REST API (or database replica / DWH view) and Track360 retrieves data on a scheduled cadence. This is the most common pattern — it keeps control on your side and requires no outbound connectivity from your systems.

Best for

Partners with existing internal APIs or reporting endpoints
Stable, batch-oriented data (daily gaming activity, transaction history)
Reconciliation and backfill workflows
Systems behind firewalls with no public webhook endpoint

Not ideal for

—Real-time event delivery (sub-second latency)
—High-frequency updates where polling creates overhead

Push — You Send Data to Track360

Your platform sends events to Track360 endpoints in real time

Your Platform

sends events

Track360 Endpoint

confirms

Your Platform

Your system pushes events (registrations, deposits, conversions) to Track360 ingestion endpoints as they occur. This gives the lowest latency but requires your platform to handle delivery, retries, and idempotency.

Best for

Real-time customer registration and attribution
Instant deposit and conversion tracking
Event-driven architectures with message queues
Platforms that prefer to control outbound data delivery

Not ideal for

—Aggregated daily data (gaming/trading activity summaries)
—Historical data migration or backfill

Hybrid — Combine Both Patterns

Push real-time events + pull batch data for reconciliation

Recommended

Real-time

Your Platform

pushes events

Track360

Scheduled

Track360

pulls batch data

Your API / DWH

The recommended approach for production integrations. Push time-sensitive events (registrations, deposits) for real-time attribution, while Track360 pulls aggregated data (activity, revenue metrics) on a daily schedule. This gives you speed where it matters and reliability everywhere else.

Best for

Production environments that need both speed and accuracy
Different entities with different freshness requirements
Data reconciliation between real-time and batch sources
High-volume integrations with complex data models

Not ideal for

—Simple integrations with a single entity type

Quick Comparison

	Pull	Push	Hybrid
Latency	Minutes to hours	Seconds	Seconds (events) + daily (batch)
Complexity	Low — expose API	Medium — handle retries	Medium — both patterns
Data freshness	Scheduled cadence	Real-time	Real-time + reconciled
Backfill support	Built-in	Requires replay	Built-in
Best entity fit	Activity, reports	Events, registrations	All entity types

Authentication

Track360 uses the OAuth 2.0 Client Credentials grant. Partners authenticate by exchanging their client_id and client_secret for a short-lived Bearer token. The token is included in the Authorization header of every subsequent API request. Tokens expire after 3600 seconds (1 hour); the client must request a new token before expiry.

Token Request

http

POST /oauth/token HTTP/1.1
Host: api.track360.io
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET

Token Response

json

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read write"
}

Authenticated Request

http

GET /api/v1/igaming/customers?page=1&per_page=50 HTTP/1.1
Host: api.track360.io
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

Important Notes

Store credentials securely. Never expose client_secret in client-side code.
Implement token refresh logic before expiry to avoid request failures.
All API requests must be made over HTTPS.
Failed authentication returns HTTP 401 with a JSON error body.
Rate limits apply per access token. See API design recommendations for details.

Customers

Represents player accounts registered on the operator platform. Each record maps a player to the affiliate or campaign that referred them.

Recommended: Near real-time (within 5 minutes of registration or status change)

Field Specification

Field	Type	Description	Validation Notes
customer_id	string	Unique partner-side customer identifier.	Must be unique across all records. Immutable after creation.
signup_date	string	Date and time the customer registered.	ISO 8601 date-time format (e.g. 2026-03-12T09:15:00Z).
last_modified_date	string	Timestamp of the last update to this record. Used for delta sync.	ISO 8601 date-time. Recommended for efficient incremental syncing.
affiliate_id	string	ID of the affiliate that referred this customer.	Must map to the partner attribution logic configured in Track360.
campaign_id	string	Campaign that drove the registration.	Recommended for granular attribution reporting.
click_id	string	Click identifier from tracking link.	Recommended for click-level attribution.
lang_id	string	Language preference of the customer.	ISO 639-1 two-letter code (e.g. "en", "de").
country_code	string	Country of the customer.	ISO 3166-1 alpha-2 (e.g. "GB", "DE"). Recommended for geo-based reporting.
kyc_status_id	string	Know Your Customer verification status.	Enum mapping documented in partner onboarding. Common values: pending, approved, rejected.
sales_status_id	string	Internal sales pipeline status.	Optional. Enum values defined per partner.
first_name	string	Customer first name.	Optional. Subject to privacy and data protection policies.
last_name	string	Customer last name.	Optional. Subject to privacy and data protection policies.
email	string	Customer email address.	Optional. Subject to privacy policy. Must be a valid email format if provided.

Sample Payload

json

{
  "customer_id": "cst_100245",
  "signup_date": "2026-03-12T09:15:00Z",
  "last_modified_date": "2026-03-15T11:40:22Z",
  "first_name": "John",
  "last_name": "D",
  "email": "[email protected]",
  "affiliate_id": "aff_204",
  "campaign_id": "cmp_981",
  "click_id": "clk_abc123",
  "lang_id": "en",
  "country_code": "GB",
  "kyc_status_id": "approved",
  "sales_status_id": "qualified"
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "iGaming Customer",
  "type": "object",
  "required": [
    "customer_id",
    "signup_date",
    "affiliate_id"
  ],
  "properties": {
    "customer_id": {
      "type": "string",
      "minLength": 1
    },
    "signup_date": {
      "type": "string",
      "format": "date-time"
    },
    "last_modified_date": {
      "type": "string",
      "format": "date-time"
    },
    "affiliate_id": {
      "type": "string",
      "minLength": 1
    },
    "campaign_id": {
      "type": "string"
    },
    "click_id": {
      "type": "string"
    },
    "lang_id": {
      "type": "string",
      "pattern": "^[a-z]{2}$"
    },
    "country_code": {
      "type": "string",
      "pattern": "^[A-Z]{2}$"
    },
    "kyc_status_id": {
      "type": "string"
    },
    "sales_status_id": {
      "type": "string"
    },
    "first_name": {
      "type": "string"
    },
    "last_name": {
      "type": "string"
    },
    "email": {
      "type": "string",
      "format": "email"
    }
  },
  "additionalProperties": false
}

Business Notes

customer_id is the primary key and must remain stable across syncs.
affiliate_id must match the affiliate identifiers configured in Track360 to ensure correct attribution.
last_modified_date enables efficient delta sync -- only records changed since the last sync need to be sent.
PII fields (first_name, last_name, email) are optional and subject to GDPR and other data protection regulations.
kyc_status_id enum values should be agreed during onboarding to ensure consistent reporting.

Transactions

Financial events on a player account: deposits, withdrawals, bonuses, and adjustments. Used for commission calculations, revenue attribution, and fraud detection.

Recommended: Near real-time (within 5 minutes of transaction completion)

Field Specification

Field	Type	Description	Validation Notes
transaction_id	string	Unique transaction identifier.	Must be globally unique. Immutable.
customer_id	string	The customer this transaction belongs to.	Must reference an existing customer_id.
transaction_type	string	Category of the transaction.	Enum: deposit, withdrawal, bonus, adjustment, other.
amount_currency	number	Transaction amount in the original currency.	Decimal precision up to 2 places. Can be negative for adjustments.
currency	string	Currency of the transaction.	ISO 4217 three-letter code (e.g. "USD", "EUR", "GBP").
transaction_date	string	When the transaction occurred.	ISO 8601 date-time format.
status	string	Current status of the transaction.	Enum values documented per partner (e.g. pending, approved, declined, reversed).
amount_usd	number	Transaction amount converted to USD.	Optional. If not provided, Track360 applies its own FX conversion.
transaction_subtype	string	Further classification within the transaction type.	Optional. Examples: "crypto", "wire", "card", "welcome_bonus".
note	string	Free-text note or internal reference.	Optional. Max 500 characters.

Sample Payload

json

{
  "transaction_id": "txn_889001",
  "customer_id": "cst_100245",
  "transaction_type": "deposit",
  "transaction_subtype": "crypto",
  "amount_currency": 1500,
  "amount_usd": 1500,
  "currency": "USD",
  "transaction_date": "2026-03-15T12:10:00Z",
  "status": "approved",
  "note": "first approved deposit"
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "iGaming Transaction",
  "type": "object",
  "required": [
    "transaction_id",
    "customer_id",
    "transaction_type",
    "amount_currency",
    "currency",
    "transaction_date",
    "status"
  ],
  "properties": {
    "transaction_id": {
      "type": "string",
      "minLength": 1
    },
    "customer_id": {
      "type": "string",
      "minLength": 1
    },
    "transaction_type": {
      "type": "string",
      "enum": [
        "deposit",
        "withdrawal",
        "bonus",
        "adjustment",
        "other"
      ]
    },
    "amount_currency": {
      "type": "number"
    },
    "currency": {
      "type": "string",
      "pattern": "^[A-Z]{3}$"
    },
    "transaction_date": {
      "type": "string",
      "format": "date-time"
    },
    "status": {
      "type": "string"
    },
    "amount_usd": {
      "type": "number"
    },
    "transaction_subtype": {
      "type": "string"
    },
    "note": {
      "type": "string",
      "maxLength": 500
    }
  },
  "additionalProperties": false
}

Business Notes

Deposits are the primary event for FTD (first-time deposit) commission triggers.
Bonus transactions should be sent separately from deposits so commission logic can distinguish organic revenue.
Status changes (e.g. approved to reversed) should be re-sent with the same transaction_id and updated status.
amount_usd is recommended for multi-currency operators to ensure consistent reporting.
Adjustment records are used for chargebacks, manual corrections, and regulatory clawbacks.

Gaming Activity

Aggregated gaming metrics per player, per day, per game type. Used for RevShare calculations (GGR/NGR-based commissions), player value segmentation, and fraud pattern detection.

Recommended: Daily (end-of-day aggregation, delivered by 06:00 UTC next day)

Field Specification

Field	Type	Description	Validation Notes
date	string	Activity date.	YYYY-MM-DD format.
customer_id	string	The player this activity belongs to.	Must reference an existing customer_id.
game_type	string	Category of game played.	Enum or documented set (e.g. slots, live_casino, table_games, sportsbook, poker).
bets_count	integer	Number of bets placed.	Non-negative integer. Optional but recommended for activity analysis.
total_bets	number	Total monetary value of all bets.	Recommended. Non-negative decimal.
wins	number	Total monetary value of player wins.	Recommended. Non-negative decimal.
ggr	number	Gross Gaming Revenue (total_bets minus wins).	Can be negative if player wins exceed bets. Optional if total_bets and wins are provided.
ngr	number	Net Gaming Revenue (GGR minus bonuses, taxes, and other deductions).	Optional. Can be negative. Used for NGR-based RevShare models.
currency	string	Currency of the monetary values.	ISO 4217 three-letter code.

Sample Payload

json

{
  "date": "2026-03-15",
  "customer_id": "cst_100245",
  "game_type": "slots",
  "bets_count": 48,
  "total_bets": 920.5,
  "wins": 815.25,
  "ggr": 105.25,
  "ngr": 97.4,
  "currency": "USD"
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "iGaming Gaming Activity",
  "type": "object",
  "required": [
    "date",
    "customer_id",
    "game_type",
    "currency"
  ],
  "properties": {
    "date": {
      "type": "string",
      "format": "date"
    },
    "customer_id": {
      "type": "string",
      "minLength": 1
    },
    "game_type": {
      "type": "string",
      "minLength": 1
    },
    "bets_count": {
      "type": "integer",
      "minimum": 0
    },
    "total_bets": {
      "type": "number",
      "minimum": 0
    },
    "wins": {
      "type": "number",
      "minimum": 0
    },
    "ggr": {
      "type": "number"
    },
    "ngr": {
      "type": "number"
    },
    "currency": {
      "type": "string",
      "pattern": "^[A-Z]{3}$"
    }
  },
  "additionalProperties": false
}

Business Notes

Aggregation key: date + customer_id + game_type + currency. One record per unique combination.
GGR = total_bets - wins. If both total_bets and wins are provided, Track360 can compute GGR automatically.
NGR is used for RevShare commission models that account for bonuses and platform costs.
Negative GGR/NGR values are valid and represent days where the player won more than they wagered.
Daily aggregation is standard. Intra-day updates should replace the full day record (upsert on aggregation key).

API Design Recommendations

Recommended Endpoints

POST/api/v1/igaming/customersCreate or upsert customer records in bulk.

GET/api/v1/igaming/customersRetrieve customers with optional filtering.

POST/api/v1/igaming/transactionsPush transaction records in bulk.

GET/api/v1/igaming/transactionsQuery transactions with filtering and pagination.

POST/api/v1/igaming/gaming-activityPush daily aggregated gaming activity records.

GET/api/v1/igaming/gaming-activityQuery gaming activity with date range and player filters.

Pagination

Cursor-based pagination is recommended for large datasets. Use the "page" and "per_page" query parameters (default: 50, max: 500). Response includes "total", "page", "per_page", and "next_cursor" fields.

Rate Limiting

1000 requests per minute per access token. Bulk endpoints accept up to 1000 records per request. HTTP 429 is returned when limits are exceeded, with a Retry-After header.

Response Envelope

All list endpoints return data in a standard envelope with pagination metadata.

Response Envelope

json

{
  "data": [
    "..."
  ],
  "meta": {
    "total": 1250,
    "page": 1,
    "per_page": 50,
    "next_cursor": "eyJpZCI6MTMwMH0="
  }
}

Validation Rules

All payloads are validated against JSON Schema before processing. Requests that fail validation receive a 422 response with detailed error messages.

General Rules

All required fields must be present and non-null.
Date and date-time fields must conform to ISO 8601.
Currency codes must be valid ISO 4217 three-letter codes.
Numeric amounts must not exceed 15 significant digits.
String fields must not exceed 500 characters unless documented otherwise.
IDs must be non-empty strings, unique within their entity scope.
Bulk payloads must not exceed 1000 records per request.

Entity-Specific Rules

Customers: customer_id, signup_date, affiliate_id are required fields. See the field specification above for type and format constraints.
Transactions: transaction_id, customer_id, transaction_type, amount_currency, currency, transaction_date, status are required fields. See the field specification above for type and format constraints.
Gaming Activity: date, customer_id, game_type, currency are required fields. See the field specification above for type and format constraints.

Onboarding Checklist

Track your progress through the integration onboarding process.

Onboarding Progress0 of 8 completed

Phase: 1 day

Phase: 2-3 days

Phase: 1-2 days

Phase: 3-5 days

Phase: 5-7 days

Ready to begin your igaming integration?

Get in touch with our integrations team to receive your API credentials and start onboarding.

Contact Integrations Team