Prop Trading

Prop Trading Integration Guide

Integration guide for proprietary trading firms connecting trader data, challenge fees, payouts, and trading activity to Track360 for affiliate commission management.

Prop Trading Integration Guide

Integration guide for proprietary trading firms connecting trader data, challenge fees, payouts, and trading activity to Track360 for affiliate commission management.

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

Integration Patterns

Prop trading integrations follow a push model where the firm sends customer registrations (with challenge metadata), financial events (challenge fees, payouts, resets), and daily trading activity summaries to Track360 via REST API. The data flows through three primary entities: Customers (trader accounts with challenge type, phase, and account size), Transactions (challenge fees, payouts, reset fees, refunds), and Trading Activity (daily aggregated trading metrics with drawdown tracking). This enables Track360 to calculate CPA commissions on challenge purchases, track the evaluation funnel from signup through funded status, detect fraud 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/prop-trading/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 trader accounts on the prop trading platform. Each record links a trader to the affiliate that referred them and includes challenge/evaluation metadata.

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.
last_modified_date	string	Timestamp of the last update to this record.	ISO 8601 date-time. Recommended for delta sync.
affiliate_id	string	ID of the affiliate that referred this customer.	Must map to the partner attribution identifiers in Track360.
campaign_id	string	Campaign that drove the registration.	Recommended for granular attribution.
click_id	string	Click identifier from the tracking link.	Recommended for click-level attribution.
lang_id	string	Language preference of the customer.	ISO 639-1 two-letter code.
country_code	string	Country of the customer.	ISO 3166-1 alpha-2.
kyc_status_id	string	Know Your Customer verification status.	Enum mapping documented in onboarding.
sales_status_id	string	Internal sales pipeline status.	—
challenge_type	string	Type of evaluation challenge (e.g. standard, aggressive, rapid, instant_funding).	Recommended. Used for commission segmentation and conversion analytics.
phase	string	Current evaluation phase (e.g. phase_1, phase_2, funded, failed).	Recommended. Used for funnel analytics and phase-based commission triggers.
account_size	number	Challenge account size in USD (e.g. 10000, 50000, 200000).	Recommended. Used for revenue segmentation and commission tier assignment.
first_name	string	Customer first name.	Subject to privacy and data protection policies.
last_name	string	Customer last name.	Subject to privacy and data protection policies.
email	string	Customer email address.	Subject to privacy policy. Must be valid email format if provided.

Sample Payload

json

{
  "customer_id": "prop_78120",
  "signup_date": "2026-03-08T16:00:00Z",
  "last_modified_date": "2026-03-14T09:30:00Z",
  "first_name": "Alex",
  "last_name": "K",
  "email": "[email protected]",
  "affiliate_id": "aff_prop_310",
  "campaign_id": "cmp_prop_55",
  "click_id": "clk_prop_442",
  "lang_id": "en",
  "country_code": "US",
  "kyc_status_id": "approved",
  "sales_status_id": "active",
  "challenge_type": "standard",
  "phase": "phase_2",
  "account_size": 100000
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "Prop Trading 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"
    },
    "challenge_type": {
      "type": "string"
    },
    "phase": {
      "type": "string"
    },
    "account_size": {
      "type": "number",
      "minimum": 0
    },
    "first_name": {
      "type": "string"
    },
    "last_name": {
      "type": "string"
    },
    "email": {
      "type": "string",
      "format": "email"
    }
  },
  "additionalProperties": false
}

Business Notes

customer_id is the primary key. For firms that create multiple challenge accounts per user, use the challenge account ID.
challenge_type and account_size together define the product purchased, which is critical for commission calculations.
phase tracks the trader through the evaluation funnel: phase_1, phase_2, funded, or failed.
Phase transitions (e.g. phase_1 to phase_2) should trigger a record update with a new last_modified_date.
PII fields are optional and subject to applicable data protection regulations.

Transactions

Financial events on a prop trading account: challenge fees, payouts, reset fees, refunds, and adjustments. These are the primary revenue and cost events for commission calculations.

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: challenge_fee, payout, reset_fee, refund, adjustment, other.
amount_currency	number	Transaction amount in the original currency.	Decimal precision up to 2 places.
currency	string	Currency of the transaction.	ISO 4217 three-letter code.
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.	Examples: "phase_1_fee", "phase_2_fee", "profit_split", "monthly_payout".
note	string	Free-text note or internal reference.	Optional. Max 500 characters.

Sample Payload

json

{
  "transaction_id": "txn_prop_220015",
  "customer_id": "prop_78120",
  "transaction_type": "challenge_fee",
  "transaction_subtype": "phase_1_fee",
  "amount_currency": 499,
  "amount_usd": 499,
  "currency": "USD",
  "transaction_date": "2026-03-08T16:05:00Z",
  "status": "approved",
  "note": "100k standard challenge purchase"
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "Prop Trading 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": [
        "challenge_fee",
        "payout",
        "reset_fee",
        "refund",
        "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

challenge_fee is the primary revenue event in prop trading. It represents the fee a trader pays to enter an evaluation challenge.
payout represents profit split payments made to funded traders. These are cost events for the firm.
reset_fee is charged when a trader resets a failed challenge. It is a secondary revenue event.
Commission is typically calculated as a percentage of challenge_fee revenue (CPA model).
Refund and adjustment transactions are used for chargebacks, promotional credits, and corrections.
Status updates should re-send the record with the same transaction_id.

Trading Activity

Aggregated trading metrics per trader, per day, per instrument. Used for monitoring challenge progress, drawdown tracking, and performance-based commission triggers.

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 trader this activity belongs to.	Must reference an existing customer_id.
instrument	string	Trading instrument (e.g. EURUSD, XAUUSD, NAS100).	Symbol as used on the trading platform.
lots_traded	number	Total number of standard lots traded.	Non-negative decimal. Precision up to 2 places.
pnl	number	Realized profit and loss for the day.	Can be negative. Represents closed positions only.
drawdown	number	Daily drawdown as a percentage of account equity.	Non-negative. Expressed as a percentage (e.g. 2.5 means 2.5%). Recommended for challenge rule monitoring.
max_drawdown	number	Maximum drawdown reached during the day as a percentage of initial account balance.	Non-negative percentage. Used for overall drawdown limit tracking.
currency	string	Currency of the monetary values.	ISO 4217 three-letter code.

Sample Payload

json

{
  "date": "2026-03-15",
  "customer_id": "prop_78120",
  "instrument": "NAS100",
  "lots_traded": 5,
  "pnl": 1240,
  "drawdown": 1.8,
  "max_drawdown": 3.2,
  "currency": "USD"
}

JSON Schema

json

{
  "$schema": "https:">//json-schema.org/draft/2020-12/schema",
  "title": "Prop Trading Activity",
  "type": "object",
  "required": [
    "date",
    "customer_id",
    "instrument",
    "lots_traded",
    "pnl",
    "currency"
  ],
  "properties": {
    "date": {
      "type": "string",
      "format": "date"
    },
    "customer_id": {
      "type": "string",
      "minLength": 1
    },
    "instrument": {
      "type": "string",
      "minLength": 1
    },
    "lots_traded": {
      "type": "number",
      "minimum": 0
    },
    "pnl": {
      "type": "number"
    },
    "drawdown": {
      "type": "number",
      "minimum": 0
    },
    "max_drawdown": {
      "type": "number",
      "minimum": 0
    },
    "currency": {
      "type": "string",
      "pattern": "^[A-Z]{3}$"
    }
  },
  "additionalProperties": false
}

Business Notes

Aggregation key: date + customer_id + instrument + currency. One record per unique combination.
pnl and drawdown are critical for determining whether a trader passes or fails a challenge phase.
drawdown represents the intra-day equity drop. max_drawdown represents the peak-to-trough since the start of the challenge.
Prop firms should send trading activity for all phases (evaluation and funded) to enable complete funnel analytics.
Commission triggers in prop trading are typically based on challenge_fee transactions, not trading activity. Activity data supports analytics and fraud detection.
Intra-day updates replace the full day record (upsert on aggregation key).

API Design Recommendations

Recommended Endpoints

POST/api/v1/prop-trading/customersCreate or upsert customer records in bulk.

GET/api/v1/prop-trading/customersRetrieve customers with optional filtering.

POST/api/v1/prop-trading/transactionsPush transaction records in bulk.

GET/api/v1/prop-trading/transactionsQuery transactions with filtering and pagination.

POST/api/v1/prop-trading/trading-activityPush daily aggregated trading activity records.

GET/api/v1/prop-trading/trading-activityQuery trading activity with date range, instrument, and trader 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.
Trading Activity: date, customer_id, instrument, lots_traded, pnl, 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 prop trading integration?

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

Contact Integrations Team