{
  "aid": "gameanalytics.com:main-1.0.0",
  "name": "DataTiger Management API",
  "type": "Index",
  "description": "\n\n## Introduction \nThe Management API allows you to setup and configure a wide range of components:\n* Applications: Every domain (i.e. your company name), can have multiple applications. Each one has a unique name and is identified by a unique ID.  \n* Workflows: Every application can have multiple workflows. Often our workflows are also referred to as user journeys. Each one has a unique name and is identified by a unique ID.  \n* A/B Tests: we believe that you should be able to test pretty much everything you are doing, therefore A/B tests can be setup for all steps of a workflow. \n\n\n## General API concepts\n* Identifiers: All managed objects are uniquely identified by a platform generated identifier.\nThis is returned when an object is created or whenever it is retrieved from the database.\n\n* Versioning: Several entities (such as the workflows) are immutable entities, as modifying them can lead to unpredicted behaviour (e.g. modifying a workflow while \nit is executing). Updating such an entity results in a new version, with its own unique identifier. \n\n## Authentication\nMost requests need to be authenticated. Management API allows two types of authentication:\n  - API Key (Bearer token)\n  - Username/Password\n  \nAs Swagger 2.0 specification cannot properly describe these authentication schemes, please use this section as a reference on how the authentication works.    \n\nIn the following sections that describe the requests, all requests that require authentication will have an optional 'Authorization' header. The API user can either \nuse this header for API token authentication or an authenticated HTTP session for username/password authentication.     \n  \n### API Key authentication\nThe API key security model is mainly targeted for backends that use the DataTiger API. Each registered user account \nof a client is assigned a unique api key which can be used to uniquely identify the user account. \nWhen a client needs to access the DataTiger API they include the assigned API with each HTTP request to the API.\n\nThe HTTP header 'Authorization' is used to specify that the requestor holds a valid access token. \nEvery request to the API must include an Authorization header with a value of the following form:\n\n```\n  Authorization: Bearer <TokenString>\n```\nThe value after 'Bearer' is the actual API key. Note: The header name is *not* case sensitive.\n\nFor instance, getting the list of all available applications using curl:\n```\ncurl -X GET \\\nhttps://staging.api.datatiger.com/applications \\\n-H 'authorization: Bearer token_placeholder' \n```\n\n### Username/Password authentication\nThis is the traditional authentication scheme where a user is presented with a login form and is asked to enter a username and a password in order to identify themselves.\n\nUpon successful login, a session cookie is returned. Any subequent HTTP request can include the cookie in its request headers and the user will be  automatically identified \nthrough the associated server-side session.\n\nThe username/password pair should be passed by a POST request to the /account/login endpoint.\n\nThis authentication method is mostly targeted to the DataTiger frontend components. If a customer implements their own authentication, the API key authentication \nis more adequate.\n\n\nHere is an simple authentication example with curl:\n```\n  curl -X POST \\\n  https://staging.api.datatiger.com/account/login \\\n    -H 'content-type: application/x-www-form-urlencoded' \\\n    -d 'username=username_placeholder&password=password_placeholder'\\\n    -c cookieFile\n```\n\nAfter the session has been authenticated (session identifier is stored in the cookieFile), it can be used for further requests (e.g. retrieve the list of available\napplications):\n```\n  curl -X GET \\\n  https://staging.api.datatiger.com/applications \\\n  -b cookieFile\n```\n\n## Workflows\nThe active workflows of an application collectively define how the DataTiger platform reacts to incoming user events.  Each workflow belongs to a single application and has\na unique name within that application.\n\n### Workflow Versioning\nWorkflows are versioned in order to allow you to edit a workflow without impacting the instances of hte workflow that are already in progress. Versions are immutable, you can always create a new version but you can never edit an existing one. Among all the versions of a workflow a single one must be assigned the ACTIVE status and this version will be instantiated by the workflow engine in response to the incoming events.\nWhen you create a new version it is automatically assigned the DRAFT status. A version with this status can be edited as many times as needed, it is a mutable object. A draft version however cannot be set to ACTIVE. The version must first be brought to an immutable status by publishing the version. Publishing the version will set its status to PUBLISHED and make it effectively immutable. Once a version reaches the PUBLISHED status, it can then be made the active one. \nOnly a single version can be active at any one time. To activate a different version, the active version must first be de-activated by setting its status back to PUBLISHED and then another version that is already in the PUBLISHED status can be activated instead. \n\nFor a workflow to be instantiated from a user event the following conditions must be true:\n* The workflow must not be already in progress for that user \n* There must be a workflow version with a status of 'ACTIVE'\n* The trigger expression must evaluate to true\n\nWhen a workflow is activated, its steps are executed starting from the workflow starting step. The processing continues until the workflow reaches a final state or fails. Depending\non the workflow, its execution may require waiting until some action if performed. \n\n### Trigger expressions\nTrigger expressions are boolean expressions over the user and event attributes (available attributes and operations are returned by the /datatypes request).\nWithin a trigger expression, an event attribute is referenced using the 'event' prefix and a user attribute with the 'user' prefix.\n\nThe expressions consist of the following:\n* AND, OR and NOT operators\n* parentheses\n* user and event properties such as 'user.UserId' or 'event.EventType'\n* Operators: One of ==, ~ (case insensitive string equality), >, <, >=, <=, !=, in the last, not in the last, in the next, not in the next, is empty, is not empty, ends with, starts with, contains\n* Literals\n  * Strings: 'strings are enclosed in single quotes'\n  * DateTime: '2011-12-03T10:15:30'. The dateTimes are always expressed in UTC\n  * Boolean: true / false\n  * Integer: 1234, -1234\n  * Float: 1.01\n* Expressions relative to now\n  * user.LastActiveOn in the last 4 MINUTES\n  \n  \nA simple example expression is as follows:\n```\n  user.LastActiveOn in the last 1 DAYS AND event.eventType == 'UserUpdated'\n```\n#### Supported values for predefined user fields\nAt the moment certain user fields support a fixed set of values. Expressions are guaranteed to work only if they compare\nagainst the following exact values\n* user.TimezoneOffset\n      * −12\n      * −11\n      * −10\n      * −09:30\n      * −9\n      * −8\n      * -7\n      * -6\n      * -5\n      * -4\n      * −03:30\n      * -3\n      * -2\n      * -1\n      * +0\n      * +1\n      * +2\n      * +3\n      * +03:30\n      * +4\n      * +04:30\n      * +5\n      * +05:30\n      * +05:45\n      * +6\n      * +06:30\n      * +7\n      * +8\n      * +08:45\n      * +9\n      * +09:45\n      * +10\n      * +10:30\n      * +11\n      * +12\n      * +12:45\n      * +13\n      * +14\n*  Language: ISO 639-1 standard. E.g. 'en', 'es' etc.\n*  Country: ISO 3166-1 alpha-2 standard. E.g. 'GB', 'US' etc.\n\n### Workflow steps\nThe workflow steps define what happens after a workflow is activated as a graph of nodes. All nodes share a set of common attributes:\n* name - gives a user friendly name to a node\n* description - useful for putting a note about the role of a specific node in the scenario\n* type - indicates the type of the node\n* transitions - From each node there's one or more labeled transitions to other nodes within the same scenario definition. This captures this\n  information, like a list of pairs of the form (label, node names) \n\nThe node type must always be defined, and can be one of the following:\n* START - Start nodes are a special type of nodes that indicate the starting point of a workflow. There's only one START node per workflow definition and it has the special and reserved name 'START'.\n* TERMINAL - This node type indicates that the workflow ends at this point, they act like terminal points in the graph stopping any further traversing of the graph of nodes. There can be many TERMINAL \n  nodes per workflow definition and they can have custom names.\n* ACTION - This node type represents a webhook action, i.e. that a URL should be invoked as a result of the workflow reaching this step.\n* WAIT - Represents an unconditional wait action for a specified amount of time.\n* CONDITION - A condition node acts as a decision point to determine which path the workflow will follow out of multiple alternatives. \n* WAIT_ON_CONDITION - A condition that is evaluated multiple times within a given time limit. If at any time the condition becomes true, \n  then the flow continues along the TRUE transition. Otherwise, if the time limit is passed and the condition is still false, then the FALSE transition is taken.\n* SENDGRID_EMAIL_ACTION - Action for sending an email through SendGrid.\n* MANDRILL_EMAIL_ACTION - Action for sending an email through Mandrill.\n* SNS_PUSH_ACTION - Action for sending Push notifications using Amazon SNS\n Distinct node types require specific properties to define their actions. All these are defined in the workflow types below.\n* ADWORDS_REMARKETING_ACTION - An action that adds the user to a Google Adwords remarketing user list.\n* TAG - Action that adds a tag to the user, can be used for segmentation or conditions later on.\n* UNTAG - Action that removes a tag from the user\n\nMultiple action parameters can include dynamic content by using a notation such as ${user.Email}. Currently three types of dynamic content are supported:\n* ${user.userAttribute} is replaced by the value of the user attribute\n* ${event.eventAttribute} is replaced by the value of the event attribute\n* ${translation.translationId[key][alt]} is replaced by looking up the 'alt' alternative of key 'key' in translation resource with ID 'translationId'. \nFor instance,  ${translation.10121[WELCOME_MSG][EN]} will be replaced with the 'EN' alternative of the key 'WELCOME_MSG' from resource 10121. The ${} \nnotation can be nested. Therefore ${translation.10121[WELCOME_MSG][${user.language}]} will be replaced according to the value in the 'language' user attribute.\n\n      \nEach type of node has a set of predefined outgoing transitions as follows:\n  \n* START\n  * OK - The 'OK' transition will be followed unconditionally when encountering a START step. \n* TERMINAL: No outgoing transitions are considered when reaching a TERMINAL. Instead the workflow is marked as completed at that point.\n* ACTION \n  * OK - Followed when the webhook call has been completed successfully\n  * ERROR - Followed in case the call couldn't be made or we received a 5xx response code\n* WAIT\n  * TIMEOUT - Followed when the requested delay has been reached.\n* CONDITION \n  * TRUE - Followed when the condition evaluates to TRUE\n  * FALSE - Followed when the condition evaluates to FALSE\n  * TIMEOUT - For conditions with a timeout setting, this will be followed when the requested delay has been reached.\n\n \nTo put everything together here is an example workflow definition in JSON:\n ```\n    {\n        \"name\": \"Example Email Workflow\",\n        \"applicationId\": 10000,\n        \"version\": {\n          \"id\": 12345,\n          \"name\": \"Welcome Flow\",\n          \"status\": \"ACTIVE\",\n          \"triggerExpression\": \"event.EventType == 'DemoEmailSend'\",\n          \"steps\": [\n             {\n                  \"id\": \"START\",\n                  \"name\": \"Start\",\n                  \"type\": \"START\",\n                  \"transitions\": {\n                      \"OK\": \"SEND_EMAIL\",\n                      \"ERROR\": \"FIN\"\n                  }\n              },\n              {\n                  \"id\" : \"SEND_EMAIL\",\n                  \"name\": \"WELCOME_EMAIL\",\n                  \"type\": \"SENDGRID_EMAIL_ACTION\",\n                  \"transitions\": {\n                      \"OK\": \"FIN\",\n                      \"ERROR\": \"FIN_ERR\"\n                  },\n                  \"templateId\": \"sendGrid ID\",\n                  \"emailTo\": \"${user.Email}\",\n                  \"emailToName\": \"${user.FirstName}\",\n                  \"replyTo\": \"your@email.com\",\n                  \"replyToName\": \"Your Name\",\n                  \"from\": \"your@email.com\",\n                  \"fromName\": \"DataTiger\",\n                  \"subject\": \"Welcome to DataTiger\",\n                  \"trackOpen\": true,\n                  \"trackClick\": true,\n                  \"substitutions\": [\n                      {\n                          \"token\": \"%firstName%\",\n                          \"value\": \"${user.FirstName}\"\n                      }\n                  ],\n                  \"sandboxed\": false\n              },\n              {\n                  \"id\": \"FIN\",\n                  \"name\": \"FIN\",\n                  \"type\": \"TERMINAL\"\n              },\n              {\n                  \"id\": \"FIN_ERR\",\n                  \"name\": \"FIN_ERR\",\n                  \"type\": \"TERMINAL\"\n              }\n          ]\n      }\n    }\n```     \n \n\n## Spreadsheets\nThe content of multicopy/multilanguage actions is specified in external 'content sources'. Here is an example of the supported content: https://docs.google.com/spreadsheets/d/1UMz7VSfe27JvGy0Lx8hWp4IhEZz-t9tW5KLKx3FbnME\n\nCurrently, only google spreadsheets with public links are supported (it's important to set the spreadsheet sharing to public, where everyone with the link can view it) \n\nThe spreadsheets can be used in the system by first adding them using the 'translations/' API. Each entry will refer to exactly one\nsheet (tab) within a spreadsheet.\n\nThe general concept is that they associate keys with content.\n\nThe supported features are:\n* content translation\n* action properties pre-population\n* random content variations\n* dynamic content variations (as opposed to random, the variation is choosen using a user/event property value)\n\nThe structure of the spreadsheet is as follows:\n* The 1st row is reserved for headers understood by datatiger\n* The leftmost column, or the one with the special header \"$key\", contains keys that identify the content. If a row has no key, the row is ignored.\n* 1st row headers that do not start with '$' are considered to be languages (e.g 'EN', 'ES', 'GR' etc)\n* $default should be the header of all content when there are no language translations (either $default or language headers are allowed, but not both)\n* $randomVariation column, if specified, allows multiple values for the same key. One of them will be selected at random for each action execution\n* $propertyVariation column, if specified, also allows multiple values for the same key. The variation that exactly matches a user/event property specified in the action step.\n* $fieldType allows auto-filling of actions. At the moment it is supported (and required) for SNS Push actions. It specifies the action field to which the content corresponds. Allowed values are:\n  * androidTitle\n  * androidMessage\n  * androidImage\n  * androidVideo\n  * iosTitle\n  * iosMessage\n  * iosImage\n  * iosVideo\n* $templateType is required for SNS Push actions and should specify the type of template to use. Available values are:\n  * TEXT\n  * TEXT_WITH_TITLE\n  * TEXT_WITH_IMAGE\n  * TEXT_WITH_TITLE_AND_IMAGE(\n  * TEXT_WITH_VIDEO\n  * TEXT_WITH_TITLE_AND_VIDEO\n* Multiple consistency checks are performed when the spreadsheets are loaded, but generally they should be both internally consistent and consistent with the actions they are used for.\n  \n",
  "url": "https://raw.githubusercontent.com/jentic/jentic-public-apis/refs/heads/main/apis/openapi/gameanalytics.com/main/1.0.0/apis.json",
  "tags": [
    "gameanalytics.com",
    "main"
  ],
  "created": "2026-04-10",
  "modified": "2026-04-10",
  "specificationVersion": "0.19",
  "access": "3rd-Party",
  "maintainers": [
    {
      "FN": "Jentic",
      "X-github": "jentic",
      "url": "https://github.com/jentic"
    }
  ],
  "apis": [
    {
      "aid": "gameanalytics.com:main-1.0.0",
      "name": "DataTiger Management API",
      "description": "\n\n## Introduction \nThe Management API allows you to setup and configure a wide range of components:\n* Applications: Every domain (i.e. your company name), can have multiple applications. Each one has a unique name and is identified by a unique ID.  \n* Workflows: Every application can have multiple workflows. Often our workflows are also referred to as user journeys. Each one has a unique name and is identified by a unique ID.  \n* A/B Tests: we believe that you should be able to test pretty much everything you are doing, therefore A/B tests can be setup for all steps of a workflow. \n\n\n## General API concepts\n* Identifiers: All managed objects are uniquely identified by a platform generated identifier.\nThis is returned when an object is created or whenever it is retrieved from the database.\n\n* Versioning: Several entities (such as the workflows) are immutable entities, as modifying them can lead to unpredicted behaviour (e.g. modifying a workflow while \nit is executing). Updating such an entity results in a new version, with its own unique identifier. \n\n## Authentication\nMost requests need to be authenticated. Management API allows two types of authentication:\n  - API Key (Bearer token)\n  - Username/Password\n  \nAs Swagger 2.0 specification cannot properly describe these authentication schemes, please use this section as a reference on how the authentication works.    \n\nIn the following sections that describe the requests, all requests that require authentication will have an optional 'Authorization' header. The API user can either \nuse this header for API token authentication or an authenticated HTTP session for username/password authentication.     \n  \n### API Key authentication\nThe API key security model is mainly targeted for backends that use the DataTiger API. Each registered user account \nof a client is assigned a unique api key which can be used to uniquely identify the user account. \nWhen a client needs to access the DataTiger API they include the assigned API with each HTTP request to the API.\n\nThe HTTP header 'Authorization' is used to specify that the requestor holds a valid access token. \nEvery request to the API must include an Authorization header with a value of the following form:\n\n```\n  Authorization: Bearer <TokenString>\n```\nThe value after 'Bearer' is the actual API key. Note: The header name is *not* case sensitive.\n\nFor instance, getting the list of all available applications using curl:\n```\ncurl -X GET \\\nhttps://staging.api.datatiger.com/applications \\\n-H 'authorization: Bearer token_placeholder' \n```\n\n### Username/Password authentication\nThis is the traditional authentication scheme where a user is presented with a login form and is asked to enter a username and a password in order to identify themselves.\n\nUpon successful login, a session cookie is returned. Any subequent HTTP request can include the cookie in its request headers and the user will be  automatically identified \nthrough the associated server-side session.\n\nThe username/password pair should be passed by a POST request to the /account/login endpoint.\n\nThis authentication method is mostly targeted to the DataTiger frontend components. If a customer implements their own authentication, the API key authentication \nis more adequate.\n\n\nHere is an simple authentication example with curl:\n```\n  curl -X POST \\\n  https://staging.api.datatiger.com/account/login \\\n    -H 'content-type: application/x-www-form-urlencoded' \\\n    -d 'username=username_placeholder&password=password_placeholder'\\\n    -c cookieFile\n```\n\nAfter the session has been authenticated (session identifier is stored in the cookieFile), it can be used for further requests (e.g. retrieve the list of available\napplications):\n```\n  curl -X GET \\\n  https://staging.api.datatiger.com/applications \\\n  -b cookieFile\n```\n\n## Workflows\nThe active workflows of an application collectively define how the DataTiger platform reacts to incoming user events.  Each workflow belongs to a single application and has\na unique name within that application.\n\n### Workflow Versioning\nWorkflows are versioned in order to allow you to edit a workflow without impacting the instances of hte workflow that are already in progress. Versions are immutable, you can always create a new version but you can never edit an existing one. Among all the versions of a workflow a single one must be assigned the ACTIVE status and this version will be instantiated by the workflow engine in response to the incoming events.\nWhen you create a new version it is automatically assigned the DRAFT status. A version with this status can be edited as many times as needed, it is a mutable object. A draft version however cannot be set to ACTIVE. The version must first be brought to an immutable status by publishing the version. Publishing the version will set its status to PUBLISHED and make it effectively immutable. Once a version reaches the PUBLISHED status, it can then be made the active one. \nOnly a single version can be active at any one time. To activate a different version, the active version must first be de-activated by setting its status back to PUBLISHED and then another version that is already in the PUBLISHED status can be activated instead. \n\nFor a workflow to be instantiated from a user event the following conditions must be true:\n* The workflow must not be already in progress for that user \n* There must be a workflow version with a status of 'ACTIVE'\n* The trigger expression must evaluate to true\n\nWhen a workflow is activated, its steps are executed starting from the workflow starting step. The processing continues until the workflow reaches a final state or fails. Depending\non the workflow, its execution may require waiting until some action if performed. \n\n### Trigger expressions\nTrigger expressions are boolean expressions over the user and event attributes (available attributes and operations are returned by the /datatypes request).\nWithin a trigger expression, an event attribute is referenced using the 'event' prefix and a user attribute with the 'user' prefix.\n\nThe expressions consist of the following:\n* AND, OR and NOT operators\n* parentheses\n* user and event properties such as 'user.UserId' or 'event.EventType'\n* Operators: One of ==, ~ (case insensitive string equality), >, <, >=, <=, !=, in the last, not in the last, in the next, not in the next, is empty, is not empty, ends with, starts with, contains\n* Literals\n  * Strings: 'strings are enclosed in single quotes'\n  * DateTime: '2011-12-03T10:15:30'. The dateTimes are always expressed in UTC\n  * Boolean: true / false\n  * Integer: 1234, -1234\n  * Float: 1.01\n* Expressions relative to now\n  * user.LastActiveOn in the last 4 MINUTES\n  \n  \nA simple example expression is as follows:\n```\n  user.LastActiveOn in the last 1 DAYS AND event.eventType == 'UserUpdated'\n```\n#### Supported values for predefined user fields\nAt the moment certain user fields support a fixed set of values. Expressions are guaranteed to work only if they compare\nagainst the following exact values\n* user.TimezoneOffset\n      * −12\n      * −11\n      * −10\n      * −09:30\n      * −9\n      * −8\n      * -7\n      * -6\n      * -5\n      * -4\n      * −03:30\n      * -3\n      * -2\n      * -1\n      * +0\n      * +1\n      * +2\n      * +3\n      * +03:30\n      * +4\n      * +04:30\n      * +5\n      * +05:30\n      * +05:45\n      * +6\n      * +06:30\n      * +7\n      * +8\n      * +08:45\n      * +9\n      * +09:45\n      * +10\n      * +10:30\n      * +11\n      * +12\n      * +12:45\n      * +13\n      * +14\n*  Language: ISO 639-1 standard. E.g. 'en', 'es' etc.\n*  Country: ISO 3166-1 alpha-2 standard. E.g. 'GB', 'US' etc.\n\n### Workflow steps\nThe workflow steps define what happens after a workflow is activated as a graph of nodes. All nodes share a set of common attributes:\n* name - gives a user friendly name to a node\n* description - useful for putting a note about the role of a specific node in the scenario\n* type - indicates the type of the node\n* transitions - From each node there's one or more labeled transitions to other nodes within the same scenario definition. This captures this\n  information, like a list of pairs of the form (label, node names) \n\nThe node type must always be defined, and can be one of the following:\n* START - Start nodes are a special type of nodes that indicate the starting point of a workflow. There's only one START node per workflow definition and it has the special and reserved name 'START'.\n* TERMINAL - This node type indicates that the workflow ends at this point, they act like terminal points in the graph stopping any further traversing of the graph of nodes. There can be many TERMINAL \n  nodes per workflow definition and they can have custom names.\n* ACTION - This node type represents a webhook action, i.e. that a URL should be invoked as a result of the workflow reaching this step.\n* WAIT - Represents an unconditional wait action for a specified amount of time.\n* CONDITION - A condition node acts as a decision point to determine which path the workflow will follow out of multiple alternatives. \n* WAIT_ON_CONDITION - A condition that is evaluated multiple times within a given time limit. If at any time the condition becomes true, \n  then the flow continues along the TRUE transition. Otherwise, if the time limit is passed and the condition is still false, then the FALSE transition is taken.\n* SENDGRID_EMAIL_ACTION - Action for sending an email through SendGrid.\n* MANDRILL_EMAIL_ACTION - Action for sending an email through Mandrill.\n* SNS_PUSH_ACTION - Action for sending Push notifications using Amazon SNS\n Distinct node types require specific properties to define their actions. All these are defined in the workflow types below.\n* ADWORDS_REMARKETING_ACTION - An action that adds the user to a Google Adwords remarketing user list.\n* TAG - Action that adds a tag to the user, can be used for segmentation or conditions later on.\n* UNTAG - Action that removes a tag from the user\n\nMultiple action parameters can include dynamic content by using a notation such as ${user.Email}. Currently three types of dynamic content are supported:\n* ${user.userAttribute} is replaced by the value of the user attribute\n* ${event.eventAttribute} is replaced by the value of the event attribute\n* ${translation.translationId[key][alt]} is replaced by looking up the 'alt' alternative of key 'key' in translation resource with ID 'translationId'. \nFor instance,  ${translation.10121[WELCOME_MSG][EN]} will be replaced with the 'EN' alternative of the key 'WELCOME_MSG' from resource 10121. The ${} \nnotation can be nested. Therefore ${translation.10121[WELCOME_MSG][${user.language}]} will be replaced according to the value in the 'language' user attribute.\n\n      \nEach type of node has a set of predefined outgoing transitions as follows:\n  \n* START\n  * OK - The 'OK' transition will be followed unconditionally when encountering a START step. \n* TERMINAL: No outgoing transitions are considered when reaching a TERMINAL. Instead the workflow is marked as completed at that point.\n* ACTION \n  * OK - Followed when the webhook call has been completed successfully\n  * ERROR - Followed in case the call couldn't be made or we received a 5xx response code\n* WAIT\n  * TIMEOUT - Followed when the requested delay has been reached.\n* CONDITION \n  * TRUE - Followed when the condition evaluates to TRUE\n  * FALSE - Followed when the condition evaluates to FALSE\n  * TIMEOUT - For conditions with a timeout setting, this will be followed when the requested delay has been reached.\n\n \nTo put everything together here is an example workflow definition in JSON:\n ```\n    {\n        \"name\": \"Example Email Workflow\",\n        \"applicationId\": 10000,\n        \"version\": {\n          \"id\": 12345,\n          \"name\": \"Welcome Flow\",\n          \"status\": \"ACTIVE\",\n          \"triggerExpression\": \"event.EventType == 'DemoEmailSend'\",\n          \"steps\": [\n             {\n                  \"id\": \"START\",\n                  \"name\": \"Start\",\n                  \"type\": \"START\",\n                  \"transitions\": {\n                      \"OK\": \"SEND_EMAIL\",\n                      \"ERROR\": \"FIN\"\n                  }\n              },\n              {\n                  \"id\" : \"SEND_EMAIL\",\n                  \"name\": \"WELCOME_EMAIL\",\n                  \"type\": \"SENDGRID_EMAIL_ACTION\",\n                  \"transitions\": {\n                      \"OK\": \"FIN\",\n                      \"ERROR\": \"FIN_ERR\"\n                  },\n                  \"templateId\": \"sendGrid ID\",\n                  \"emailTo\": \"${user.Email}\",\n                  \"emailToName\": \"${user.FirstName}\",\n                  \"replyTo\": \"your@email.com\",\n                  \"replyToName\": \"Your Name\",\n                  \"from\": \"your@email.com\",\n                  \"fromName\": \"DataTiger\",\n                  \"subject\": \"Welcome to DataTiger\",\n                  \"trackOpen\": true,\n                  \"trackClick\": true,\n                  \"substitutions\": [\n                      {\n                          \"token\": \"%firstName%\",\n                          \"value\": \"${user.FirstName}\"\n                      }\n                  ],\n                  \"sandboxed\": false\n              },\n              {\n                  \"id\": \"FIN\",\n                  \"name\": \"FIN\",\n                  \"type\": \"TERMINAL\"\n              },\n              {\n                  \"id\": \"FIN_ERR\",\n                  \"name\": \"FIN_ERR\",\n                  \"type\": \"TERMINAL\"\n              }\n          ]\n      }\n    }\n```     \n \n\n## Spreadsheets\nThe content of multicopy/multilanguage actions is specified in external 'content sources'. Here is an example of the supported content: https://docs.google.com/spreadsheets/d/1UMz7VSfe27JvGy0Lx8hWp4IhEZz-t9tW5KLKx3FbnME\n\nCurrently, only google spreadsheets with public links are supported (it's important to set the spreadsheet sharing to public, where everyone with the link can view it) \n\nThe spreadsheets can be used in the system by first adding them using the 'translations/' API. Each entry will refer to exactly one\nsheet (tab) within a spreadsheet.\n\nThe general concept is that they associate keys with content.\n\nThe supported features are:\n* content translation\n* action properties pre-population\n* random content variations\n* dynamic content variations (as opposed to random, the variation is choosen using a user/event property value)\n\nThe structure of the spreadsheet is as follows:\n* The 1st row is reserved for headers understood by datatiger\n* The leftmost column, or the one with the special header \"$key\", contains keys that identify the content. If a row has no key, the row is ignored.\n* 1st row headers that do not start with '$' are considered to be languages (e.g 'EN', 'ES', 'GR' etc)\n* $default should be the header of all content when there are no language translations (either $default or language headers are allowed, but not both)\n* $randomVariation column, if specified, allows multiple values for the same key. One of them will be selected at random for each action execution\n* $propertyVariation column, if specified, also allows multiple values for the same key. The variation that exactly matches a user/event property specified in the action step.\n* $fieldType allows auto-filling of actions. At the moment it is supported (and required) for SNS Push actions. It specifies the action field to which the content corresponds. Allowed values are:\n  * androidTitle\n  * androidMessage\n  * androidImage\n  * androidVideo\n  * iosTitle\n  * iosMessage\n  * iosImage\n  * iosVideo\n* $templateType is required for SNS Push actions and should specify the type of template to use. Available values are:\n  * TEXT\n  * TEXT_WITH_TITLE\n  * TEXT_WITH_IMAGE\n  * TEXT_WITH_TITLE_AND_IMAGE(\n  * TEXT_WITH_VIDEO\n  * TEXT_WITH_TITLE_AND_VIDEO\n* Multiple consistency checks are performed when the spreadsheets are loaded, but generally they should be both internally consistent and consistent with the actions they are used for.\n  \n",
      "image": "",
      "baseURL": "https://api.datatiger.com/",
      "humanURL": "https://github.com/jentic/jentic-public-apis/tree/main/apis/openapi/gameanalytics.com/main/1.0.0",
      "version": "1.0.0",
      "tags": [
        "gameanalytics.com",
        "main"
      ],
      "properties": [
        {
          "type": "OpenAPI",
          "name": "OpenAPI definition",
          "url": "https://raw.githubusercontent.com/jentic/jentic-public-apis/refs/heads/main/apis/openapi/gameanalytics.com/main/1.0.0/openapi.json",
          "mediaType": "application/openapi+json"
        },
        {
          "type": "GitHubRepo",
          "url": "https://github.com/jentic/jentic-public-apis/tree/main/apis/openapi/gameanalytics.com/main/1.0.0"
        }
      ]
    }
  ]
}