Three generations of Salesforce real-time event delivery for external clients.
Streaming API (CometD) — original real-time event channel. Uses CometD long-polling under the hood. Channels are URLs like /event/MyEvent__e or /data/AccountChangeEvent. Client establishes a session, subscribes to channels, receives events.
javascript // CometD client (legacy) cometd.subscribe('/event/Order_Created__e', (msg) => { ... });
Strengths: well-supported across many languages, browser-friendly via SocketJS or similar. Weaknesses: long-polling is heavier than modern protocols, replay-from-id has limits, scaling beyond a few hundred concurrent subscribers gets expensive.
Pub/Sub API (newer) — a gRPC-based bidirectional stream. Replaces CometD as the modern protocol for high-volume, high-throughput event subscription.
python # Pub/Sub API client (modern) stub = pubsub_api_pb2_grpc.PubSubStub(channel) for event in stub.Subscribe(...): ...
Strengths: lower latency, higher throughput, native streaming over HTTP/2, better replay support, Schema registry integration. Weaknesses: gRPC tooling is newer for some languages; Salesforce documentation still maturing.
When to use which:
- External middleware (Mulesoft, Snowflake CDC connectors) — these prefer Pub/Sub API now.
- Custom integrations in Java/Python/Node — Pub/Sub API for new builds.
- Browser-based subscribers — CometD/Streaming API still works; Pub/Sub API is more for backend-to-backend.
- Legacy code running on CometD — keep working; migrate when convenient.
What flows over both: Platform Events, Change Data Capture events, generic streaming channels.
Salesforce direction: Pub/Sub API is the strategic future. CometD is supported indefinitely but new investment is in Pub/Sub.