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.

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.
tracking_data	string	Track360 will send it in URL and get it back in API.	Max 50 characters.
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",
  "tracking_data": "2001_1000_abcdefg",
  "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",
    "tracking_data"
  ],
  "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
    },
    "tracking_data": {
      "type": "string",
      "minLength": 1,
      "maxLength": 50
    },
    "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, tracking_data 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