Firehose Guarantees and Best Practices
Firehose API provides the following guarantees as described in this documentation. Typically, many customers will be sharing internal Firehose event queues and delivery characteristics may be impacted by total traffic exacted on these event queues.
Each and every request will be handled within no more than 1s. If no data is fetched from a Firehose internal queue within that time, Firehose will return an empty collection. This may happen even if there is still some data further in the queue for particular account but Firehose had to pass through other accounts’ data. When such a situation occurs your position can be moved forward and you should just query the API again with your new, desired position.
You must always re-check the
top property to determine if there still is data in the stream—do not rely on the number of items returned in the page.
This SLA is guaranteed as a function of a data generation rate. Firehose guarantees that event(s) representing user interaction will be available in a few seconds, provided that number of such interactions is less than 10 per second.
Data appearing in Firehose API stream will eventually become consistent. Firehose API client will attempt to find a consistent state that’s subject to the Latency SLA.
The Firehose API stream is returned in order of event processing times (e.g. from the oldest to newest event) for a single resource
id (e.g. particular deal instance).
Firehose does not provide ordering guarantees between different resources e.g. no correlation between changes on deals and contacts. Neither does it provide ordering guarantees between different instances of single type of resource - e.g. between different deals.
This number will be an upward-trending number that exists in every snapshot. You can use it to determine which snapshot is older within particular resource
While you cannot see two different snapshots with the same number, you can view the same sequence more than once with the same snapshot (duplicates from at-least-once delivery guarantee). Gaps may occur in the delivery of this number.
Events in Firehose API are delivered with at-least-once delivery guarantees. This means that some events may appear within the stream more than once but they will always maintain their expected order. Duplicates are identical, and display the same data while retaining the same sequence number. As a result, clients should handle events in an idempotent way.
Event Stream Endpoint
This endpoint keeps full events history for the last 72 hours. The events older than 72 hours will be deleted. You can use this data to back fill your application if it has been down for some time. Firehose guarantees that retention time is at least 72h, sometimes it could be a little bit longer.
User interaction with Base UI (Web or Mobile) may produce one or more events in Firehose API. Firehose tries to aggregate changes to produce single event per user interaction, but some data changes in Base happen asynchronously and Firehose API favours low latency over smaller number of events. As a result you may see more than one event in Firehose from the same user interaction. For example when changing address of your contact and customer and prospect status at the same time you will see separate events as customer and prospect status changes are made asynchronously in Base.