Introduction
This section details Split's API. The Split API uses resource-oriented URLs, uses status codes to indicate the success or failure of requests and returns JSON from all requests.
You can use the Split API to push data into Split, get data out of Split, build custom integrations, or build on top of the Split platform.
Getting Started?
If you're just getting started with Split, we encourage your to visit our help center site. You'll learn how to set up our SDKs and release a feature without re-deploying your application.
Authentication
How to authenticate against the Split API
All requests to Split's API must be authenticated with an admin API key. The admin key type provides private and universal access to current and future admin APIs. Creating an API key is simple and can be done in the API Keys section of settings.
Learn more about API keys
To best familiarize yourself with using API keys in Split, visit our main documentation for more details.
An authentication header must be added containing your API key for the request. Authenticate with the API by adding an authorization header containing your admin API key.
Authorization: Bearer ADMIN_API_KEYRate Limiting
Our public API is guarded by a rate limiter using several techniques to prevent abuse. Calls to this API that are rate limited will return a 429 status code along with relevant headers that indicate the remaining quota (X-RateLimit-Remaining-Org and X-RateLimit-Remaining-IP) and how long to wait until the next window specified in seconds (X-RateLimit-Reset-Seconds-Org and X-RateLimit-Reset-Seconds-IP). When rate limited, users should retry after a number of seconds equal to or greater than the maximum time of the last two "X-RateLimit-Reset-Seconds-XXX" headers.
API rate limiting and SDKs
Rate-limiting only applies to this public API and does not affect the API used by the SDKs to serve feature evaluations.
Get Workspaces
Retrieves the workspaces for an organization.
Retrieves the Workspaces for an organization.
Environments Overview
An environment reflects a stage in the development process, such as your production application or your internal staging environment. During the feature release process, Splits can be promoted through the various environments; allowing for a targeted roll out throughout the development process.
At this time the creation and editing of environments are limited to administrators within the Split application.
With the API you can get information about the environments that exist within your organization.
{
"id": "string", // Server populated identifier
"name": "string", // Display name
"production": "boolean" // Production environment or not
}Traffic Types Overview
A traffic type is a particular identifier type for any hierarchy of your customer base. Traffic types in Split are completely customizable and can be any database key you choose to send to Split, i.e. a user ID, account ID, IP address, browser ID, etc. Essentially, any internal database key you're using to track what "customer" means to you.
The creation and editing of traffic types are limited to administrators within the Split application.
With the API you can get information about the traffic types that exist within your organization.
Learn more about traffic types
To best familiarize yourself with using traffic types, visit our main documentation for more details.
{
"id": "string", // Server populated identifier
"name": "string", // Display name
"displayAttributeId": "string" // (Optional) Attribute used for display name in UI
}Attributes Overview
Attributes are properties of a traffic key in Split. With the API you can get, save, and delete attributes programmatically.
Attribute fields are also created automatically when new keys are saved to Split. Those newly created attributes are created with an unknown data type and with no display or description information. It is recommended to customize and/or update your attributes to ensure each attribute has a data type and attribute description.
The data type is an optional parameter which is used for display formatting purposes. This parameter is not used to validate the values on inbound keys, but incorrectly typed data will be displayed as their raw string. The data types available include string, datetime, number, and set; this value can also be left null and the data will be treated as a string. Values for datetime fields are expected to be passed as milliseconds past the epoch. Values for set fields are expected to be passed in a string as comma separated values. If an unsupported data type is sent you will receive a 400 error code as a response.
{
"id": "string", // Attribute identifier, same as used in identity value map
"trafficTypeId": "string", // Traffic type this attribute is associated with
"displayName": "string", // (Optional) How the attribute will be displayed in the UI, defaults to the id
"description": "string", // (Optional) A description of the attribute
"dataType": "string", // (Optional) The data type of the attribute used for display formatting, defaults to displaying the raw string. Must be one of: null, "string", "datetime", "number", "set"
"isSearchable": boolean // (Optional) If the attribute should appear in segment and whitelist search
}Save Attribute
Save an attribute for a traffic type ID. The attribute is created if it does not exist and is overwritten completely if it does.
Delete Attribute
Delete an attribute by its traffic type and attribute ID. This also removes any stored data for that attribute from all keys in Split.
Identities Overview
You can populate your identities within Split to enrich and simplify the experience when using the Split web console. Learn more about using this data in Split.
Your keys and information are used to help search for customers during segment and whitelist creation as well when navigating impressions for any Split.
With the API you can save, update and delete identities programmatically.
{
key: "string", // Key used for getTreatment() calls
trafficTypeId: "string", // Traffic Type Identifier
environmentId: "string", // Environment Identifier
values: { // Attribute Values (key: Attribute Id, value: value)
key: "string",
}
}Save Identity
Create or overwrite a single key for a given traffic type and environment.
Save Identities
Create or overwrite identities for a given traffic type and environment.
Update Identity
Update a single key for a given traffic type and environment. Any provided attribute values will be overwritten, but existing values will otherwise remain.
Segments Overview
The Rest API allows you to manage your Segments programmatically.
Using this API you can get Segments, as well as update a Segments keys in an environment.
Learn more about segments
To best familiarize yourself with using Segments in your deployment and rollout strategy, visit our main documentation for more details.
Segment
Below is the configuration for a Segment in a specific environment such as production or staging.
Note that Segments can be configured differently for each environment.
{
"name": String,
"environment": { "id": String, "name": String },
"trafficType": { "id": String, "name": String },
"creationTime": Number
}Create Segment
Create a Segment in your organization given a traffic type. This API does not configure the Segment in any environment.
{
"name": String, // Mandatory
"description": String // Optional
}Delete Segment
Delete a Segment from your organization. This will automatically unconfigure the Segment Definition from all environments.
{
"name": String, // Mandatory
"description": String // Optional
}Enable Segment in Environment
Activate a Segment in an environment to be able to set its definitions.
Deactivate Segment in Environment
Deactivate a Segment in an environment.
List Segments in Environment
Retrieves the Segments given an environment.
{
"objects": [ SEGMENT_IN_ENVIRONMENT ], // Array of Segments returned
"offset": Number, // Offset received
"limit": Number, // Limit received
"totalCount": Number // Total number of Segments for the environment
}Update Segment Keys in Environment via CSV
Bulk upload a CSV file containing a list of identifiers. The segment must exist before calling this endpoint.
Update Segment Keys in Environment via JSON
Bulk upload a list of identifiers via JSON to a segment. The segment must exist before calling this endpoint.
{"keys":["id1", "id2", "id3"], "comment":"a comment"}Remove Segment Keys from Environment
Delete a list of segment keys via JSON from an existing segment.
{"keys":["id1", "id2", "id3"], "comment":"a comment"}Splits Overview
The Rest API allows you to manage your Splits programmatically.
Using this API, you can create, get, delete Splits, as well as update a Split's targeting definition in an Environment.
Learn more about Splits
To best familiarize yourself with using Splits in your deployment and rollout strategy, visit our main documentation for more details
Split
A Split is our term for a feature flag, toggle, or experiment. In REST terms it has the following schema:
{
"name": String,
"description": String,
"trafficType": { "id": String, "name": String },
"creationTime": Number,
"tags" : [{ "name": String }]
}The REST Endpoints available for a Split are:
It's worth noting that this object does not contain any information regarding the configuration or rollout plan for any specific environment.
In the same way as the web console, creating a Split involves setting a name and a traffic type (and possibly a description).
After the Split is created, it is possible to update it for any specific environment, using the REST API calls for Split Definition.
Split Definition
A Split Definition is the configuration of a Split in a specific environment such as production or staging.
{
“name”: String,
“environment”: { "id": String, "name": String },
“trafficType“: { "id": String, "name": String },
“killed”: Boolean,
“treatments”: [ Treatment ],
“defaultTreatment”: String,
“trafficAllocation”: Number,
“rules”: [ Rule ],
“defaultRule”: [ Bucket ],
“creationTime”: Number,
“lastUpdateTime”: Number,
}The minimum required fields for configuring a Split Definition are treatments, defaultTreatment, and defaultRule.
For detailed examples on how to perform actions on a Split Definition, check:
Treatment
A treatment is a state of a Split. A simple feature flag has two treatments: on and off. An experiment can have any number of treatments.
{
“name”: String,
"configurations": String,
“description”: String,
“keys”: [ String ],
“segments”: [ String ]
}Keys are used to show the specified treatment for a specific customer. It is analogous to the Whitelist section on the Web Console.
In the same way, Segments is used to show the treatment to users in a particular segment.
'Configurations' are JSON representations of components of your feature that might you want to be able to change on the fly (e.g. you could set the color of a button to red or set number of retries allowed on an API endpoint via these configurations)
Rule
A Rule consists of a Condition and a list of Buckets.
When the Split Definition is evaluated, if the Condition of this Rule is met, then the customer will be evaluated and fall in the sticky distribution specified in the Buckets
{
“condition”: Condition,
“buckets”: [ Bucket ]
}Note that you do not need to provide all treatments for each rule, however, the sum of treatment sizes in a single Rule must be 100.
Condition
A Condition consists of different Matchers. A customer satisfies a Condition only of it satisfies all the Matchers.
{
“combiner”: "AND",
“matchers”: [ Matcher ]
}Note that when configuring or updating a `Split Definition, there is no need to specify the combiner, since for now, Split only allows AND combiner.
Bucket
A bucket represents a sticky distribution of customers into treatments of a Split.
{
“treatment”: String,
“size”: Number
}Matcher
A Matcher represents the logic for selecting a specific subset of your customer population.
{
“negate”: Boolean,
“type”: MatcherType,
“attribute”: String,
"string": String,
"bool" : Boolean,
"strings" : [ String ],
"number" : Number,
"date" : Number,
"between": { "from" : Number, "to" : Number },
"depends": { "splitName": String, "treatment": String }
}
Note that depending on the type, different fields are required. All the rest of the fields do not need to be set.
Matcher Type
Split supports the following Matcher Types.
{
IN_SEGMENT,
EQUAL_SET,
ANY_OF_SET,
ALL_OF_SET,
PART_OF_SET,
ON_DATE,
ON_OR_AFTER_DATE,
ON_OR_BEFORE_DATE,
BETWEEN_DATE,
BOOLEAN,
EQUAL_NUMBER,
LESS_THAN_OR_EQUAL_NUMBER,
GREATER_THAN_OR_EQUAL_NUMBER,
BETWEEN_NUMBER,
IN_LIST_STRING,
STARTS_WITH_STRING,
ENDS_WITH_STRING,
CONTAINS_STRING,
MATCHES_STRING,
IN_SPLIT,
}IN_SEGMENT
When using this type, the matcher selects the set of customers that fall within a Segment.
Fields
string: Mandatory.
negate: Optional.
EQUAL_SET
This matcher selects customers with a multi-valued attribute equal to a Set of provided String literals. Since this is a Set based matcher, the order of the Set does not matter.
Fields
strings: Mandatory.
attribute: Mandatory
negate: Optional.
ANY_OF_SET
This matcher selects customers with a multi-valued attribute containing any of a Set of provided String literals. Since this is a Set based matcher, the order of the Set does not matter.
Fields
strings: Mandatory.
attribute: Mandatory
negate: Optional.
ALL_OF_SET
This matcher selects customers with a multi-valued attribute containing every String literal in a provided Set. Since this is a Set based matcher, the order of the Set does not matter.
Fields
strings: Mandatory.
attribute: Mandatory
negate: Optional.
PART_OF_SET
This matcher selects customers with a multi-valued attribute that is a subset of a Set of values. Since this is a Set based matcher, the order of the Set does not matter.
Fields
strings: Mandatory.
attribute: Mandatory
negate: Optional.
ON_DATE
The ‘is on’ matcher is helpful for doing date equalities. Note that this matcher drops the time component of a DateTime when doing the comparison. Thus, the values 1457382451 and 1457382452 fall on the same date even though they represent different times.
Fields
date: Mandatory. Milliseconds since epoch.
attribute: Mandatory
negate: Optional.
ON_OR_AFTER_DATE
The ‘on or after date’ matcher is helpful for targeting customers that performed an action after a given time. As an example, you can use this matcher to target customers that registered or bought something after a certain time.
Note that this matcher ignores time fields smaller than minutes. Specifically; seconds, milliseconds, and nanoseconds are ignored when doing the comparison. In other words, you can compare dates down to the minute field.
Thus, the values 1457382451 and 1457382471 will be equal to one another, even though they represent different seconds.
Fields
date: Mandatory. Milliseconds since epoch.
attribute: Mandatory
negate: Optional.
ON_OR_BEFORE_DATE
The ‘on or before date’ matcher is helpful for targeting customers that performed an action before a given time. As an example, you can use this matcher to target customers that registered or bought something before a certain time.
Note that this matcher ignores time fields smaller than minutes. Specifically; seconds, milliseconds, and nanoseconds are ignored when doing the comparison. In other words, you can compare dates down to the minute field.
Thus, the values 1457382451 and 1457382471 will be equal to one another, even though they represent different seconds.
Fields
date: Mandatory. Milliseconds since epoch.
attribute: Mandatory
negate: Optional.
BETWEEN_DATE
This matcher is an AND between ON_OR_AFTER_DATE and ON_OR_BEFORE_DATE. The same rules of ignoring time fields smaller than seconds apply.
Fields
between: Mandatory. It is an object that contains two fields, from and to. Both fields
are dates represented by milliseconds since epoch.
attribute: Mandatory
negate: Optional.
BOOLEAN
This is a self-explanatory matcher. At least, we think so :-).
Fields
bool: Mandatory.
attribute: Mandatory
EQUAL_NUMBER
This matcher selects the subset of customers that have an attribute equal to a numeric value.
Fields
number: Mandatory.
attribute: Mandatory
negate: Optional.
LESS_THAN_OR_EQUAL_NUMBER
This matcher selects the subset of customers that have an attribute that is less than or equal to a numeric value.
Fields
number: Mandatory.
attribute: Mandatory
negate: Optional.
GREATER_THAN_OR_EQUAL_NUMBER
This matcher selects the subset of customers that have an attribute that is greater than or equal to a numeric value.
Fields
number: Mandatory.
attribute: Mandatory
negate: Optional.
BETWEEN_NUMBER
A matcher of this type will match if the received number is between the two ones specified.
Fields
between: Mandatory. It is an object that contains two fields, from and to.
attribute: Mandatory
negate: Optional.
IN_LIST_STRING
This matcher selects customers with an attribute or key that falls within a whitelist. The whitelist is encoded within the strings field. This matcher is case sensitive.
Fields
strings: Mandatory.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
STARTS_WITH_STRING
This matcher selects customers with an attribute or key starting with any of a list of strings. This matcher is case sensitive. Note that the strings should not be regex patterns, they are string literals that are used for exact prefix matching.
Fields
strings: Mandatory.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
ENDS_WITH_STRING
This matcher selects customers with an attribute or key ending with any of a list of strings. This matcher is case sensitive. Note that the strings should not be regex patterns, they are string literals that are used for exact suffix matching.
Fields
strings: Mandatory.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
CONTAINS_STRING
This matcher selects customers with an attribute or key containing any of a list of strings. This matcher is case sensitive. Note that the strings should not be regex patterns, they are string literals that are used for exact contains matching.
Fields
strings: Mandatory.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
MATCHES_STRING
This matcher selects customers with an attribute or key that matches the regex pattern in string.
Fields
string: Mandatory.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
IN_SPLIT
This matcher is useful when you want to consider the experience of a customer for one Split in deciding the experience for the same customer for another Split. As an example, consider a team working on a brand new homepage and another team responsible for a new widget design on that new homepage. The Split controlling the widget should take into account whether or not the new homepage is turned on for a user.
Fields
depends: Mandatory. This object contains two fields, splitName and treatment.
attribute: Optional. If it is set the match will be triggered against the attribute. If it is not set, the match will be against the key provided.
negate: Optional.
Default Rule
The Default Rule is simply a list of buckets.
If a specific id did not match any Rule, then this rule is applied in order to determine the treatment to be returned.
Note that you do not need to provide all treatments in the Default Rule, however, the sum of treatment sizes must be 100
{
"rules" : [{ "..." }],
"defaultRule": [
{ "treatment": "on", size: 90 },
{ "treatment": "off", size: 10 }
]
}If no rule is matched for the id, then the Default Rule is evaluated and there is a 90% chance that the result will be on, and 10% chance that it will be off.
Create Split
Create a Split in your organization given a traffic type. This API does not configure the Split in any environment.
List Splits
Retrieves the Splits for an organization.
{
"objects": [ SPLIT ], // Array of Splits returned
"offset": Number, // Offset received
"limit": Number, // Limit received
"totalCount": Number // Total number of Splits
}Get Split
Retrieves the Split.
{
"name": String,
"description": String,
"trafficType": URN, // Containing id and name of the Traffic Type
"creationTime": Number // Milliseconds since epoch
}Delete Split
Delete a Split from your organization. This will automatically unconfigure the Split Definition from all environments. An SDK calling this Split will return "control".
Create Split Definition in Environment
Configures a Split Definition for a specific environment.
{
"treatments": [ Treatment ], // Mandatory
"defaultTreatment": String, // Mandatory
"rules": [ Rule ], // Optional
"defaultRule": [ Bucket ], // Mandatory
"comment": String // Optional
}Detailed information of the payload structure can be found on Split Grammar.
Get Split Definition in Environment
Retrieves a Split Definition given the name and the environment.
{
"name": String,
"environment": URN, // Containing id and name of the environment
"killed": Boolean,
"treatments": [ Treatment ],
"defaultTreatment": String,
"trafficAllocation": Number, // Between 0 and 100
"rules": [ Rule ],
"creationTime": Number, // Milliseconds since epoch
"lastUpdateTime": Number // Milliseconds since epoch
}Detailed information of the payload structure can be found on Split Grammar.
Partial Update Split Definition in Environment
Updates a Split Definition for a specific environment.
This API call allows to update any field of a split using JsonPatch.
A few examples below.
curl -v -X PATCH \
-d '[{"op": "replace", "path": "/killed", "value": true}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Productioncurl -v -X PATCH \
-d '[{"op": "replace", "path": "/trafficAllocation", "value":50}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Productioncurl -v -X PATCH \
-d '[{"op": "replace", "path": "/defaultTreatment", "value": "on"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionThe example above will set the default treatment to "on".
Add a Key (i.e user) to a treatment whitelist with no keys
The following example will add the key "3" as the first key in the whitelist of the first treatment.
curl -v -X PATCH \
-d '[{"op": "add", "path": "/treatments/0/keys", "value": ["3"]}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionAdd a Key (i.e user) to a treatment whitelist with existing keys
The following example will add the key "4" to the whitelist for the first treatment, given that a treatment that already has one or more keys.
curl -v -X PATCH \
-d '[{"op": "add", "path": "/treatments/0/keys/-", "value": "4"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Productioncurl -v -X PATCH \
-d '[{"op": "remove", "path": "/treatments/0/keys/2"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionThe example above will remove the third element of the whitelist for the first treatment.
Replace a Key (i.e user) in a treatment whitelist
curl -v -X PATCH \
-d '[{"op": "replace", "path": "/treatments/0/keys/0", "value": "7"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionThe example above replaces the first element of the whitelist for the first treatment and sets it to "7".
Add a Segment (i.e employees) to a treatment whitelist
Given a treatment that already has a segment in the whitelist.
curl -v -X PATCH \
-d '[{"op": "add", "path": "/treatments/1/segments/-", "value": "beta"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionThe example above will add the segment "beta" to the second treatment.
Remove a Segment (i.e employees) from a treatment whitelist
curl -v -X PATCH \
-d '[{"op": "remove", "path": "/treatments/0/segments/1"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionThe example above will remove the second segment from the whitelist for the first treatment.
Rename a Treatment
Given the Split definition,
{
"...",
"treatments" :[{ "name":"on" }, {"name":"off" } ],
"rules" :[
{
"...",
"buckets": [
{ "treatment":"on","size":80 },
{ "treatment":"off","size":20 }
]
}
],
"defaultRule": [
{ "treatment":"on", "size": 50 },
{ "treatment":"off", "size": 50}
],
"..."
}
To rename "on" to "first_version",
curl -v -X PATCH \
-d '[{ "op": "replace", "path": "/rules/0/buckets/0/treatment", "value": "first_version" }, { "op": "replace", "path": "/treatments/0/name", "value": "first_version" }, { "op": "replace", "path": "/defaultRule/0/treatment", "value": "first_version" }]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Production{
"...",
"treatments" :[{ "name":"on" }, {"name":"off" } ],
"rules" :[{"..."}],
"defaultRule": [
{ "treatment":"on", "size": 50 },
{ "treatment":"off", "size": 50}
],
"..."
}
To add a rule,
curl -v -X PATCH \
-d '[{"op": "add", "path": "/rules/0", "value": {"buckets":[{"treatment":"on","size":50},{"treatment":"off","size":50}],"condition":{"matchers":[{"type":"IN_SEGMENT","string":"employees"}]}}}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Production
curl -v -X PATCH \
-d '[{"op": "remove", "path": "/rules/1"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/Productioncurl -v -X PATCH \
-d '[{"op": "replace", "path": "/baselineTreatment", "value":"off"}]' \
-H 'Content-Type:application/json' \
-H 'Authorization: Bearer ADMIN_API_KEY' \
https://api.split.io/internal/api/v1/splits/paywall_beta/environments/ProductionFull Update Split Definition in Environment
Performs a full update of a Split Definition for a specific environment.
Remove Split Definition from Environment
Unconfigures a Split Definition for a specific environment. Any SDK calling this split will return "control" for the selected environment.
Lists Split Definitions in Environment
Retrieves the Split Definitions given an environment.
{
"objects": [ SPLIT_DEFINITIONS ], // Array of Split Definitions returned
"offset": Number, // Offset received
"limit": Number, // Limit received
"totalCount": Number // Total number of Split Definitions
}Events Overview
This API allows you to send events programmatically to Split. Record events that measure your customer behavior across your application including clicks, views, checkout events, page load times, or any event that measures your customer experience.
Metrics can then be calculated from these events to measure the results of experiments rolled out as Splits. Learn more about Creating a Metric in Split.
In the examples below you'll see that the payload can take up to six arguments. The proper data type and syntax for each are:
- key: Represents the customer_id used in your
getTreatmentcall and firing this track event.- Expected Data Type: String
- trafficTypeName: Represents the traffic type of the customer id in the track call.
- Expected Data Type: String
- You can only pass values that match the names of Traffic Types that you have defined in your instance of Split.
- eventTypeId: Represents the event type that this event should correspond to.
- Expected Data Type: String
- Full requirements on this argument are:
- 80 characters or less
- Starts with a letter or number
- Contains only letters, numbers, hyphen, underscore, or period.
- This is the regular expression we use to validate the value:
[a-zA-Z0-9][-_\.a-zA-Z0-9]{0,62}
- value: (optional) Represents the value to be used in creating the metric. This field can be sent in as null or 0 if you intend to purely utilize the count function when creating a metric.
- Expected Data Type: Integer or Float
- environmentName: Represents the environment in Split you want this event to be mapped to.
- Expected Data Type: String
- You can only pass values that match the names of Environments that you have defined in your instance of Split.
- timestamp: (optional) Represents the time in milliseconds since epoch that the event occurred.
- Expected Data Type: Integer
- properties: (optional) A dictionary of key value pairs that can be used to filter your metrics. Learn more about event property capture here. Split currently supports three types of properties: strings, numbers, and booleans.
- Expected Data Type: Integer, Float, Boolean, or String