Track360 API — iGaming

The Track360 API provides a lightweight, JSON-based interface for Brands and Partner systems to report customer records and business activity in real time. It is designed to serve as the bridge between operational systems and the Track360 attribution, tracking, and reporting layer.

What this API is for

This API enables two primary functions. First, it allows a Brand to register new customers in Track360 along with the marketing attribution values that brought them in. Second, it allows the Brand to continuously report activity events — deposits, withdrawals, gross gaming revenue (GGR), net gaming revenue (NGR), bets, or aggregated daily statistics — against those customers.

What the integration enables

Once integrated, Track360 receives a reliable stream of customer and activity data from the Brand. This data is then used to:

• Attribute each customer to the correct acquisition source using tracking parameters
• Compute commissions, revenue share, CPA, and hybrid models for affiliates and partners
• Produce business intelligence reports based on actual customer KPIs
• Reconcile performance across campaigns, affiliates, and traffic sources

Who this document is for

This guide is written for the technical teams responsible for implementing the integration on the Brand side — including backend engineers, integration leads, CRM/platform owners, and product managers overseeing the tracking infrastructure. Familiarity with HTTP, JSON, and basic API authentication is assumed.

The integration follows a simple, directional pattern: tracking data originates at Track360, is echoed back by the Brand during customer creation, and is then enriched over time with business activity reported by the Brand. Track360 never pulls data from the Brand — the Brand always pushes data to Track360 via HTTPS requests.

End-to-end data flow

Responsibilities

What data is sent to Track360

• Customer data — identifying information about a newly registered user and the tracking parameters that were originally delivered to the Brand with that user’s traffic.
• Activity data — financial and behavioral events generated by the customer after registration, such as deposit, ggr, ngr, etc., or aggregated daily performance.

All Track360 API endpoints are protected by an API key issued per Brand. The key is passed in a single HTTP header and must be present on every request — unauthenticated requests will be rejected.

Authentication method

Track360 uses a simple API key scheme based on a Brand Token. There is no OAuth flow, no session to manage, and no signing algorithm — the token is static and is configured once per Brand in the Track360 platform.

Required header

Token source

The Brand Token is defined in the Brand Settings section of the Track360 platform. It is associated with a single Brand and should be treated as a secret credential.

Example request header

Content-Type: application/json
x-api-key: b1f4e7a2-9c3d-4e1b-8a77-2f9e6d3c5a81

Both Track360 endpoints follow a uniform, predictable contract. Understanding these conventions once applies everywhere the API is used.

Request format

Batching — multiple records per request

Both the Customer API and the Activity API accept a JSON array of records in a single request body. This allows a Brand to send a single customer or event, or to submit multiple records in one call for efficiency — particularly useful for periodic batch reporting or replaying historical data.

Uniqueness

The customerId field must be unique per Brand. This identifier is the primary link between a customer record and every activity event reported for that customer. If the same customerId is sent again to the Customer API, Track360 will treat the call as an update to the existing record.

Update behavior

The Customer API supports both creation and update through the same endpoint. A record with a new customerId is created; a record with an existing customerId overwrites or augments the stored customer data. This makes it straightforward to resend enriched information — such as a CRM sales status or updated contact details — without using a separate update endpoint.

Tracking parameters are the backbone of the attribution pipeline. They are appended to URLs by Track360 when traffic is delivered to the Brand, and they must be captured, preserved, and returned in the Customer API call for that user. Without them, Track360 cannot associate a customer with the campaign, affiliate, or traffic source that produced them.

Why tracking parameters matter

Track360 relies entirely on the parameters returned by the Brand to attribute a customer. No fingerprinting, cookie syncing, or server-to-server tracking substitutes for these values. If they are missing or altered, the customer will appear in Track360 as an unattributed record, and downstream reporting — including commission calculations — will not be correct for that customer.

How Track360 sends them

Tracking parameters are appended to the destination URL when Track360 routes traffic to the Brand’s landing page. The Brand is responsible for capturing these values on page load, persisting them across the user’s session (commonly via cookie, local storage, or server-side session), and associating them with the customer at the point of registration.

Returning them in the Customer API

When the customer completes registration, the Brand must include the captured parameters in the JSON body of the Customer API request. Parameter names in the request should match the names received — for example, a tracking_data received in the URL is returned as a tracking_data field in the payload.

Example combinations

{
  "tracking_data": "2001_1000_abcdefg"
}

{
  "tracking_data": "campaign_7_aff_42_creative_b"
}

The Customer API registers a new customer in Track360 or updates an existing customer record. Every customer that the Brand acquires should be registered through this endpoint, along with the tracking parameters originally received with that customer’s traffic.

When to call this endpoint

The Customer API should be called when a user completes registration on the Brand’s platform. It may also be called later to enrich the record — for example, when a CRM status changes, when KYC completes, or when additional metadata becomes available. Because the endpoint supports updates, there is no need for a separate update call.

Request structure

The request body is a JSON array in which each element represents a single customer. Each object carries a unique identifier, registration metadata, basic profile information, and the tracking parameters that were received when the customer first landed on the Brand’s site. Additional fields (for example, CRM sales status) may be added as agreed with Track360.

Field definitions

Example request body

[
  {
    "customerId":    "12386a7c-d843-4b12-9ad3-3ae295d49c27",
    "regtime":       "2025-07-21 08:46",
    "country":       "US",
    "firstName":     "Alex",
    "lastName":      "Taylor",
    "tracking_data": "2001_1000_abcdefg"
  }
]

Implementation notes

• Send this request as soon as the registration flow completes, so that attribution is not delayed.
• Multiple customers may be sent in a single array — useful for batch reprocessing or bulk imports.
• Any call with an existing customerId updates that customer; design your logic to allow safe resubmission.
• All tracking parameters originally received must be returned here; missing parameters cannot be reconstructed later.

The Activity API is used to report business events against previously registered customers. These events cover all revenue-relevant KPIs and any aggregated metric the Brand wishes to track. Activity events are the foundation of all performance reporting inside Track360.

Supported event types (KPIs)

The Activity API is KPI-flexible — there is no fixed enumeration. Any KPI agreed between the Brand and Track360 can be reported. The following are commonly used for iGaming:

Event reporting logic

Each object in the array represents either a single event or an aggregated event (for example, a daily summary carrying several KPIs together). At a minimum, each object must include:

• customerid — ties the event back to a registered customer.
• eventname — identifies what the event represents.

Beyond these two required fields, the object carries whatever numeric or descriptive values are relevant to the event being reported, including value, currency, and any additional details the Brand and Track360 have agreed to capture.

Field definitions

Example — single event per record

[
  {
    "eventname":  "Deposit",
    "eventid":    "1234",
    "createtime": "2025-07-20 11:03",
    "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
    "Value":      "250.00",
    "Currency":   "USD"
  },
  {
    "eventname":  "GGR",
    "eventid":    "1235",
    "createtime": "2025-07-21 11:03",
    "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
    "Value":      "50.00",
    "Currency":   "USD"
  }
]

KPI flexibility

There is no fixed list of permitted eventname values — the KPIs reported may be tailored to the Brand’s business. New KPIs can be introduced over time without any code changes on Track360’s side, as long as the naming is agreed in advance so that reports render them correctly.

Grouping by date or by KPI type

Two kinds of grouping are supported, either or both of which may be chosen during event configuration:

• Group by date — report aggregated daily activity for a customer instead of transaction-level events. This reduces volume and simplifies reconciliation for Brands whose upstream system provides daily summaries.
• Group by KPI type — segment the same KPI across product lines. For iGaming, common groupings include Casino, Sports, Poker, and Bingo, enabling reporting and commission logic to differ per product.

Additional per-event details

Extra descriptive or financial fields can be configured alongside the core event data. Typical examples include deposit type (credit card, bank transfer, crypto, etc.) and a normalized amount in a reporting currency such as USD. These additional fields are defined during integration setup and must be agreed between the Brand and Track360.

The following examples show the most common shapes of activity payloads for iGaming. They are grounded in the capabilities described above and illustrate how different KPIs translate into concrete JSON bodies.

{
  "eventname":  "Deposit",
  "eventid":    "TX-9981422",
  "createtime": "2025-07-20 11:03",
  "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
  "Value":      "250.00",
  "Currency":   "USD"
}

{
  "eventname":  "GGR",
  "createtime": "2025-07-21",
  "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
  "Value":      "50.00",
  "Currency":   "USD"
}

{
  "eventname":  "NGR",
  "createtime": "2025-07-21",
  "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
  "Value":      "45.00",
  "Currency":   "USD"
}

{
  "eventname":  "DailyStats",
  "createtime": "2025-07-21",
  "customerid": "12386a7c-d843-4b12-9ad3-3ae295d49c27",
  "GGR":        "50.00",
  "NGR":        "45.00",
  "Bets":       "550.00",
  "Games":      "15",
  "Currency":   "USD"
}

The tables below consolidate all fields documented in the preceding sections for quick reference. Use them as a lookup during implementation and QA.

Customer payload — field reference

Activity payload — field reference

Tracking parameters — field reference

The following practical notes distill the integration’s most important operational considerations. They are not new requirements — they are emphasis on the details that most commonly affect integration quality in production.

Before starting

• Obtain the Brand Token from Brand Settings in Track360 and store it securely.
• Confirm the Track360 base URL assigned to the Brand (e.g. https://partners.yourbrand.com).
• Agree on the set of tracking parameters that Track360 will deliver and the Brand will return.
• Agree on the set of KPIs / event names that will be reported through the Activity API.
• Decide whether eventid will be used, and if so, which system generates it.

Consistency that must be preserved

• customerId must remain stable for the lifetime of a customer — it is the link between every activity event and the customer record.
• Tracking parameter names returned in the Customer API should match the names received on the landing URL.
• KPI naming (Deposit, GGR, NGR, …) must be aligned with the agreed configuration on Track360’s side, so reports render correctly.

What must be returned for attribution to work

Every tracking parameter received with inbound traffic must be returned in the Customer API call for that customer. Missing parameters cannot be reconstructed later — customers registered without the original parameters will remain unattributed in reporting.

How event grouping is decided

Two grouping decisions are made during integration configuration and should be finalized before go-live:

• Temporal grouping — whether events are reported per transaction or aggregated by date.
• Product grouping — whether the same KPI is broken down by product line (for iGaming: Casino, Sports, Poker, Bingo).

Currency and KPI reporting considerations

Activity events carry their native Currency. If the Brand operates in multiple currencies, currency conversion rules can be defined so that KPIs can be reported and compared consistently in a single reporting currency. The rules are configured on the Track360 side and do not require changes to the Brand’s request payloads.

Additional per-event detail

Where the business requires richer context — such as deposit type, payment method, or an already-normalized USD amount — these fields can be added to the activity payload per agreement with Track360. Design the payload to be forward-compatible so new fields can be introduced without breaking existing logic.

Use this checklist before moving the integration to production. Every item below is grounded in the contract described in this document.