Introduction
Pub/Sub API gives external applications one way to publish and subscribe to Salesforce events. The official documentation describes it as a gRPC and HTTP/2 based API for event-driven integrations on the Salesforce event bus.
Supported event types
- High-volume platform events, including custom and standard events.
- Change Data Capture events.
- Real-time event monitoring events.
Salesforce also documents what Pub/Sub API does not support, including PushTopic events and generic events. That boundary matters when modernizing older streaming integrations.
Durability and replay
Salesforce stores event messages for 72 hours, and subscribers can use replay IDs to resume consumption within that retention window.
Good design practice
- Store replay IDs durably.
- Treat replay IDs as opaque.
- Plan reconnect and catch-up logic explicitly.
Operational risk
- If the subscriber stays offline too long, the retention window can be missed.
- Replay IDs are not guaranteed to be contiguous.
- Consumers must handle duplicate-safe processing.
Payload handling
Salesforce documents Pub/Sub API payload handling around Avro serialization. That means subscriber implementations should not treat the payload as an ad hoc JSON message stream. Teams need a clear deserialization layer and stable consumer contract handling.
Integration example
A payment platform may subscribe to Payment_Status_Changed__e and related CDC events through Pub/Sub API. A single external service can then handle custom business events and record-change notifications through one Salesforce integration surface instead of multiple transport models.
Tradeoffs
Pub/Sub API is strong when you want one modern event interface and durable replay behavior. The tradeoff is that consumers need to understand the event format and build proper deserialization, replay, and resubscription logic. That is usually the right trade for serious integration platforms, but it is heavier than a simple webhook or one-off polling integration.
