Fast Track: The only engagement platform built for iGaming

Overview

An Origin identifies which brand, site or registration source a player belongs to. Every player in Fast Track belongs to exactly one origin, and that assignment comes from the data you send us.

Origins are what allow a single Fast Track environment to serve more than one brand. Instead of running a separate integration and environment per brand, you integrate once and separate your brands with the origin field.

Fast Track uses the origin to decide:

which players a segment, activity or lifecycle applies to
which sender identity a message goes out with: email sender, SMS sender name, site URL, unsubscribe page
how results are broken down in reporting and analytics

Origins are worth setting correctly even if you only run one brand today. Getting the field right from day one means adding a second brand later needs no re-integration.

Typical Use Case

Multi-brand operators. Several casino or sportsbook brands on one platform, each needing its own sender identity and campaigns.
Multi-market brands. One brand operating under different domains or licences per market, where communication must reflect the local site.
Multi-product setups. Separating a casino site from a sportsbook site while keeping a single player view.
White label providers. One platform integration serving many downstream skins.

What you get

Capability	What it means per origin
Segmentation & targeting	Activities and segments are targeted at one or more origins. Selecting several combines them with OR logic, and you see the player count broken down per origin.
Lifecycles	Origins form part of a lifecycle's entry conditions, across automated, scheduled and templated lifecycles.
Sender identity	Base Site URL, SMS Sender Name, Sender Email Address and Email Sender Name are configured per origin.
Unsubscribe & shortlinks	Each origin has its own unsubscribe page and shortlink domain, so links point at the right site.
Content	Email templates are assigned to origins, allowing brand-specific creative from a shared library.
Reporting	Origin is available as a dimension in Insights and Data Studio, so activity and revenue can be split by brand.

User IDs must be unique across the environment

This is the single most important requirement on this page.

A user ID must identify exactly one player across your entire Fast Track environment, not one player per origin.

User ID 1 must exist under one origin only. The same user ID must never appear under two different origins.

Fast Track resolves a player from the user ID alone. If the same ID exists on two brands, the two players are indistinguishable and their data will be merged into a single profile.

Fast Track accepts numeric IDs of up to 11 digits by default. Longer or alphanumeric IDs are supported but must be configured before you start sending data. Raise it with your Integration Manager early, as changing it later requires a full migration.

Requirements 📃

Before enabling Origins, your platform must meet all of the following:

Unique user IDs across the whole environment. See above.
One Operator API for all origins. The same Operator API host and the same authentication must serve every origin.
A consistent origin value for every player, on every brand, returned by the Operator API.
origin on every Real-Time Data event. The field is required, for all users and all brands.
One transport for all origins. Events from every origin must arrive over the same REST API, RabbitMQ or Kafka connection.
A decision on the origin query string parameter. See Operator API request format.

The origin field

origin appears in three places. All three must carry the same value for a given player.

Where	Direction	Required
Real-Time Data event payloads	You to Fast Track	Always
Operator API User Details response	You to Fast Track	Always
Operator API request query string	Fast Track to you	Only if enabled for your environment

Origin key format

The origin key is an identifier, not a display label. Fast Track validates it when the origin is created:

This field only allows lowercase letters, numbers, underscores and dashes.

Valid keys:

Uppercase letters, spaces, dots and any other punctuation are rejected.

The key configured in Fast Track and the value you send must be identical. A mismatch means the player is not assigned to the origin you expect.

Operator API request format

By default, Fast Track calls your Operator API with the user ID alone. The user ID is always sufficient to identify the player, because IDs are unique across the environment.

The origin query string parameter

Some platforms need to know which brand a request relates to, for example to credit a bonus on the correct brand. If that applies to you, Fast Track appends the origin to the request as a query string parameter.

Parameter	In	Type	Value
origin	Query string	string	The origin key, exactly as configured in Fast Track

With the parameter enabled, the same request looks like this:

It is applied across Operator API endpoints, not only User Details:

Expressed against the generic host:

This is brand context for your API, not a way of identifying the player. Tell your Integration Manager during onboarding if you need it. It is enabled per environment, not per request.

Your API must still return a player when called without the parameter. Some Fast Track processes, user migration in particular, call your endpoints with the user ID alone.

What we need from you per origin

For each brand you want to run as an origin, Fast Track needs:

Item	Notes
Origin key	The identifying value you will send us. Usually the brand name.
Brand logo	Used to identify the origin in the backoffice.
Base Site URL	The origin's site address.
Sender Email Address	Used when contacting players by email.
Email Sender Name	The from-name shown on email.
SMS Sender Name	The visible sender name on SMS.
Shortlink domain	Requires a CNAME record pointed at the Fast Track load balancer.
Unsubscribe domain	Requires a CNAME record pointed at the Fast Track load balancer.

If you operate a brand across several markets, these are usually needed per target country as well as per brand.

Setting this up 🚀

1. Agree your origins with Fast Track

Provide the details above for each brand. Fast Track creates the origins and configures the environment.

2. Send origin on every Real-Time Data event

origin is a required property on all Real-Time Data events, including Registrations, Login, Payments, Casino, Bonus and Sportsbook.

The origin on a player's Registration event determines the origin that player is assigned to.

3. Return the matching origin from your Operator API

The User Details response must return the same origin for that player.

The origin in your User Details response and the origin on your Real-Time Data events must agree. If they disagree, player data and targeting will not behave as expected.

4. Confirm whether you need the origin query string parameter

See Operator API request format.

Rules and constraints

One origin per player. A player belongs to exactly one origin.
The origin must already exist. Send only values matching an origin configured in Fast Track.
Consistency is required. The same player must carry the same origin on every event and in every API response.
Deleted keys are not immediately reusable. Deleting an origin is a soft delete and its key stays reserved. Ask Fast Track Support if you need one released.

Common pitfalls

Pitfall	Result
The same user ID used on more than one origin	Two players collapse into one profile. Data, targeting and reporting all become unreliable.
Sending an origin value that doesn't match a configured origin key	The player isn't assigned to the intended origin and is missed by targeting.
Different origin in events versus User Details	Inconsistent player data and unreliable targeting.
Origin missing from some event types	Those events can't be attributed correctly.
Different Operator API hosts or credentials per brand	Not supported. One host and one authentication must serve all origins.
An Operator API that only works when origin is supplied	Blocks user migration and other processes that call without it.
Using a display name rather than the origin key	Origin keys are identifiers. Use the lowercase key format above.