If no more messages are available, this method will be blocked for 30 seconds and return an HTTP 204 response (No Content) after. It is intended that the client should re-invoke this method as soon as it has processed the messages received in the previous call.
If the client is able to consume messages more quickly than they become available, each call will be initially blocked and there is no need to delay before re-invoking this method.
A datafeed will expire if its unread capacity is reached. For a standard datafeed, this will be 250 queued messages, and for firehose 500 messages.
A datafeed can only be consumed by one client thread at a time. For example, polling the datafeed by two threads may lead to messages being delivered out of order.
It is mandatory to read the datafeed from the same Agent instance that it was created on, bypassing any load balancer that may be in front of a multi-Agent configuration.
The caller needs to be the same user that created the datafeed.
There is no guarantee of message delivery for this endpoint. If errors occur while processing the request, either on the server or the API Agent, the messages that would have been returned may not be readable from the current stream. The messages are still available via the Messages endpoint and the Content Export function.
For an in-cloud Agent, if the pod is bounced, the read call will block indefinitely and will not return an HTTP 204. The client should set a 35 second timeout and if met, recreate the datafeed. This is a known issue with Amazon ELBs.
Reading emojis: if you are using a bot to check an emoji received by the
datafield returned by the response payload, keep in mind that the
unicodeof the emoji might show some inconsistencies. To avoid that, we recommend the use of the
shortcodfield since it is consistent with all the systems (Android, iOS, and Internet Browser).