Firehose
This document refers to deprecated parts of the platform and has been left intact to help customers with legacy integrations. In order to access the latest platform features and documentation, please go to https://docs.sentiance.com.
Motivation
Why Firehose?
A common need among Sentiance customers is to react to their user's activities. You might want to enhance their experience in a travel app based on their mode of transport, or show them relevant offers when they plan to visit a store. Receiving updates of a user's event stream in real-time is an invaluable tool.
Enter the Firehose: our way of sending you updates on the activity stream of your users.
Webhooks
Delivery of messages in Firehose is done via Webhooks. Webhooks are a well-known and much used integration pattern and quite popular in linking applications for message delivery.
Setup
Things We Need from You
In order to receive events over Firehose we need you to set up an endpoint capable of receiving HTTP POST requests in JSON format, compressed with gzip, secured by BasicAuth. Messages are based on events that take place on the Sentiance platform. You tell us which events you want to listen to and the details of your endpoint through the Insights webhooks dashboard and we start sending you messages whenever we have a new event for a user of your app.
Our US and Australian customers can go to
https://insights.d4.sentiance.com
andhttps://insights.e6.sentiance.com
respectively.
We also need you to create a HTTP GET version of the webhook endpoint. This should be secured with the same BasicAuth credentials as the POST version and should respond with a JSON in the following format.
This ensures that the data gets sent to the correct Application ID.
In case incorrect credentials are received by either POST or GET endpoint, a status 401 is expected as response.
Message Format
All messages will have a general envelope format and a data
field with a unique format per event type.
The POST body will always be a JSON object with a data
field which is an array of multiple events. These events could be of different types and from different users, batched into one request.
Each item will have a meta
JSON object with fields message_type
and message_timestamp
. On webhooks configured to listen to only one type of event, the message_type
will always be the same. If you wish to receive more than one type of event on the same webhook, you will need to check the message_type
field to determine which event you are looking at. The message_timestamp
field will tell you when the event was generated in our system. These timestamps are in ISO 8601 format.
Based on the value of message_type
you'll need to parse the data
field.
All messages are gzipped before sending over the wire.
Batching
To save on network bandwidth we batch messages sent over the webhook. Batching is done over both time and space, the defaults are 5 seconds and 1 MB.
That is to say that once we have 1 MB worth of data or 5 seconds have passed, we will create a batch of data and send a request. These values can be configured when creating or updating a webhook. The ranges are 1 - 300 seconds and 23kb - 4MB.
Note: Batching by size is done before gzip compression.
Delivery
On each successful delivery we expect a 200 OK Status Code. If we don't get one, we will keep retrying (see below). We try our best to guarantee at least once delivery. This means we might sometimes send multiples of the same message if our server fails to recognise a successful acceptance of our POST. We don't read the body when the response is a 200 OK.
Security
To ensure that your messages originate from Sentiance and not from a malicious third party, we will set a BasicAuth header on every request as per the requested configuration in the webhooks dashboard.
Your connection must be secured with TLS. https://www.ssllabs.com/ is a great place to inspect your endpoint and ensure it meets ongoing security standards. We require a B grade or above to ensure all data is transmitted securely.
Furthermore all our calls originate from the following dedicated IPs, if you wish to protect your endpoint with IP whitelisting please add these to your whitelist.
52.213.134.71
34.252.131.81
We perform a list of verifications before activating webhooks.
We check for a valid SSL certificate present on your endpoint
Valid BasicAuth credentials
Correct implementation of BasicAuth security
Intended AppID to which messages are being delivered
The ability to successfully receive messages
We will be calling the GET endpoint to ensure the data gets sent to the correct Application ID. We will also call the endpoints with incorrect credentials to verify they are being rejected.
We will be sending test payloads to the POST endpoint to ensure that the endpoint can handle our data formats. These test payloads can be identified by looking for the HTTP header sentiance-payload-type: test
Once automated verifications have passed, your request will be forwarded to a member of the Sentiance Client team for final validation. If everything looks good your Webhook will be made active and you will be informed over email. In case there is a problem a Sentiance Delivery Team member will reach out to you.
Errors
Handling them like a Champ
If your endpoint is unreachable, whether it be network fluctuations or a temporary server outage, we aim to still attempt delivery. Firehose expects a 200 OK response for every message sent. If it gets back anything else, it will keep retrying with exponential backoff starting from 100 ms up to 5 minutes.
Retention
Every webhook has a Message TTL. This is the amount of time we will keep messages for that webhook before discarding them. This ensures that we avoid sending stale information.
For example, if your Message TTL has been set to 30 minutes and your endpoint has been down for 40 minutes, on resuming you will only receive messages that are up to 30 minutes old. Messages from the first 10 minutes of downtime will have been dropped.
You can request a specific Message TTL during Webhook setup.
Testing
To test out the viability of your newly created endpoint, you can try the following curl:
You'll have to change the url being targeted, but for the rest you can use as is. The encoded basic auth credentials are sentiance
and securepassword
. The provided example file is a Transports event as shown at the end of the page.
Additionally example server implementations can be found here.
FAQ
Do you support multiple endpoints per webhook?
Unfortunately we don't. We have tried to keep the design of the Firehose as simple and fast as possible which means keeping the core feature-set minimal and maintainable.
Can I receive messages from multiple apps on the same endpoint?
While this is possible, it comes with the catch that you won't know which messages are from which app. One way to remedy that is to use a dynamic route parameter in your endpoint that encodes the appId.
For example:
https://example.com/webhook/appId1
https://example.com/webhook/appId2
With https://example.com/webhook/:appId
being the route that handles and parse appId
. Check our example server implementation for how such an endpoint might be written.
Event Reference
Car Transports
Note: This message is sent for both the driver and the passenger. Do not assume that the user of this transport is necessarily the driver.
All Transports
If you subscribe to All Transports, you will receive events for all transport modes including car. The primary difference between mode car and other modes is the presence of behavior_scores
on car transports.
Example 1
Example 2
Predictions
Locations
Stationaries
Moments
Moment message type sends moment upsert (moment_changed) and moment removal (moment_removed) actions which can be correlated by the moment identifier (moment_id).
Last updated