Streaming API Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Getting Started with Streaming API
Push Technology
Bayeux Protocol, CometD, and Long Polling
Streaming API Terms
How the Client Connects
Message Reliability
Message Durability
Streaming Event Features
Streaming API vs. Pub/Sub API
Differences Between Change Events Received with Streaming API vs. Pub/Sub API
API End-of-Life Policy
Code Examples
Client Connection Considerations
PushTopic Events (Legacy)
Generic Events (Legacy)
Monitoring Event Usage
PDF

Message Reliability

For clients subscribed with API version 37.0 or later, Streaming API provides reliable message delivery by enabling you to replay past events through durable streaming. Clients subscribed with API version 36.0 or earlier might not receive all messages in some situations.

When using the Streaming API endpoint, note these important considerations.

  • Durable streaming is supported when clients subscribe at the Streaming API endpoint using API version 37.0 or later. The PushTopic or platform event version affects only the fields available in the event message, but doesn’t affect the client subscription version.
  • To ensure continuity during instance refreshes and org migrations, we recommend using your org’s My Domain login URL in the Streaming API endpoint.

Note

In API version 37.0 and later, Streaming API stores events for 24 hours, enabling you to replay past events. With durable streaming, messages aren’t lost when a client is disconnected or isn’t subscribed. When the client subscribes again, it can fetch past events that are within the 24-hour retention period. The ability to replay past events provides reliable message delivery.

In API version 36.0 and earlier, Streaming API doesn’t maintain client state nor keeps track of what’s delivered. The client might not receive messages for several reasons, including:
  • When a client first subscribes or reconnects, it might not receive messages that were processed while it wasn’t subscribed to the channel.
  • When a client disconnects and starts a new handshake, it could be working with a different application server, so it receives only new messages from that point on.
  • Some events are dropped when the system is being heavily used.
  • If an application server is stopped, all messages being processed but not yet sent are lost. Clients connected to that application server are disconnected. To receive notifications, the client must reconnect and subscribe to the topic channel.