Custom On Site Notifications
Integrating a custom On Site Notifications solution/provider as part of your Operator API
Fast Tracks supports two different providers for On Site Notifications, our own and "Operator API Provider" meaning that you can do what you want to do on your side.
Fast Track On Site Notifications Service
The following endpoints can be built as a part for your Operator API:
⬆️ POST /channels/site/single
⬆️ POST /channels/site/batch
The Operator can then forward these requests to the On Site Notifications system for processing and answer back with the respective responses.
Pre-Requisites
- Advice Fast Track if any rate limiting should be taken into consideration. (If you plan to implement rate limiting please contact Fast Track before, so we can guide you on supported implementation)
- Advice Fast Track if any batch maximums should be taken into consideration.
- Provide Fast Track with any credentials specific for the integrated providers (if required)
Send On Site Notification (Single)
A single On Site Notification send request will contain the data of each individual notification in separate requests to the API.
Endpoint Implementation
Implement the endpoint in the format below to support single-send On Site Notification through API.
⬆️ POST <operator-api-base-url>/channels/site/single
Request Header
The header of the sent request contains an x-api-key which is a token required to authenticate the API calls at the endpoint. This token needs to be passed on to Fast Track in order to make these requests.
Request Body Schema
Refer to the following example of a single notification request sent by Fast Track. The description of each field is listed in the table below it.
| Key | Type | Desctiption |
|---|---|---|
activity.id | integer | A unique identifier of the On Site Notification |
activity.brand_id | integer | The unique identifier of the brand on Fast Track |
activity.user_id | string | The unique identifier of the player |
activity.activity_id | integer | The unique identifier of the activity setup in Fast Track |
activity.action_group_id | integer | The unique identifier of the action group which the On Site Notification originates from Fast Track |
activity.trigger_hash | string | Trigger hash |
activity.action_id | integer | The unique identifier of the individual action from Fast Track |
Expected Responses
The Operator API should return the responses for each individual On Site Notification message respectively to avoid unrelated storage of On Site Notification data.
Successful HTTP 200-299 JSON Response
The site_notification_id will be a unique identifier generated by the Operator API which allows Fast Track to identify that particular On Site Notification message in order to update its delivery status after it is sent.
ERROR Non-200 response JSON Response
Erroneous responses are typically associated with HTTP status codes 400s or 500s. The response should contain an "error" field with a description to show what went wrong and assist with troubleshooting.
The responses from the Operator API will be handled differently depending on the class of the HTTP status code. The table below gives a summary of how the HTTP status are handled separately.
| HTTP Status Codes | Description |
|---|---|
200-299 | Successfully Delivered. Fast Track will acknowledge the message and start processing the next message in the queue. |
400-499 | Non Successful. When receiving this error, Fast Track will skip the On Site Notification message. Additionally, it will send its data to Failed Actions, if the service is enabled. |
500 or any other status code which is not listed above | Non Successful. The service fatals and Fast Track will keep retrying until a 200 response is received. |
Batch On Site Notification
Batch On Site Notification helps to process a collection of On Site Notifications in one request to the API. The number of messages within the batch request is limited by a set integer amount in the configuration and sent within a configured time span, even when the batch is not yet full.
Endpoint Implementation
Implement the endpoint in the format below to support batch-send On Site Notification through API.
⬆️ POST <operator-api-base-url>/channels/site/batch
Request Header
The header of the sent request contains an x-api-key which is a token required to authenticate the API calls at the endpoint. This token needs to be passed on to Fast Track in order to make these requests.
Request Body Schema
Here is an example of expected format when batching the requests. It is similar to the Single On Site Notification request but the requests are stored in an array, one after the other.
| Key | Type | Description |
|---|---|---|
activity.id | integer | A unique identifier of the On Site Notification |
activity.brand_id | integer | The unique identifier of the brand on Fast Track |
activity.user_id | string | The unique identifier of the player |
activity.activity_id | integer | The unique identifier of the activity setup in Fast Track |
activity.action_group_id | integer | The unique identifier of the action group which the On Site Notification originates from Fast Track |
activity.trigger_hash | string | Trigger hash |
activity.action_id | integer | The unique identifier of the individual action from Fast Track |
Expected Responses
The below responses should be returned by the Operator API.
Successful HTTP 200 JSON Response
The "activity.id" initially sent in the request will be returned back in the response as "id". This is required to help Fast Track identify the individual On Site Notification message in the initial batch request.
The site_notification_id will be a unique identifier generated by the Operator API, which Fast Track will use to identify the related On Site Notification message when updating its status.
If any of the listed categories ("successful", "failed" or "fatal") do not have an associated On Site Notification, they should be returned as an empty array.
The request need to include one of the properties successful, failed or fatal
The logic flow on how the response will be handled is very similar to how the HTTP status codes are handled in the Single On Site Notification endpoint. The sole difference is that the response with a status code 200 will be handled instead, according to the message's category in the response.
| Response Category | Description |
|---|---|
successful | Successfully Delivered. Fast Track will acknowledge the message and start processing the next batch in the queue. |
failed | Non Successful. When receiving this error, Fast Track will skip the On Site Notification message. Additionally, it will send its data to Failed Actions, if the service is enabled. |
fatal | Messages will be retried |
Any other messages that are not listed within the response will be retried.
ERROR (non 500 response) JSON Response
Fast Track will only support HTTP Status Code 200 in batching. The whole batch request will be retried if any other status code is received with the following response.