The Event Bus and the Pub/Sub API
Module 2 of 8 in the chapter Events, chapter 11 of the Integration Architect course. Each module stands on its own. Previous: The Reversed Arrow · Next: Platform Events and Change Data Capture
The question this module answers: What is the event bus, and what does a subscriber actually do to stay on the line?
One In, Many Out
Section titled “One In, Many Out”In class I ask: one event goes onto the bus. How many come out? It feels like a trick question, and it is. If a flow is listening, it gets one. If a trigger is listening, it gets one. If an outside system is subscribed, it gets one too. One goes in and many can come out, each to its own listener, each on its own line.
And they don’t all hear it at the same moment. One listener gets it in under a second. Another was away and hears it when it calls back. A third might ask for it 71 hours and 59 minutes later. A single event could be delivered zero times, three times, or anywhere in between. Chapter 7 drew that picture, each in its own time, and chapter 4 built the inside listener in Flow. This module is the outside listener: the system that dials in.
Events Aren’t Records
Section titled “Events Aren’t Records”Here’s the thing that trips up people who know Salesforce well. A platform event looks like an object. It has a name ending in __e instead of __c, and it has fields. But it isn’t a record.
With an sObject, an Account or a custom object, you insert, update and delete it, and you can come back later and query it, because it has a record ID. With an event, you can only publish it. It doesn’t get a record ID you can look up. You don’t choose where it goes. The bus adds it to the end of its channel, and that’s it. You can’t query it afterwards. The only way to see an event is to subscribe to its channel.
Each kind of event has its channel, called a topic. A custom platform event named Order_Event__e is on the topic /event/Order_Event__e (GetTopic (opens in a new tab), Pub/Sub API Developer Guide, checked 2026-11-07). Steve Trucking’s Delivery Update from chapter 4 is /event/Delivery_Update__e. Through the Pub/Sub API you can listen to high-volume platform events, your own and Salesforce’s standard ones, Change Data Capture events, and real-time event monitoring events. Not the old ones: the Pub/Sub API “doesn’t support legacy events, such as standard-volume platform events, PushTopic events, and generic streaming events” (Event Types (opens in a new tab), same guide, checked 2026-11-07).
The Pub/Sub API
Section titled “The Pub/Sub API”The Pub/Sub API is the line a system outside Salesforce uses to get onto the event bus. Three things make it different from the REST API you know from chapter 8 (Pub/Sub API Features (opens in a new tab), same guide, checked 2026-11-07):
- It’s gRPC, not REST. gRPC is an open framework for calling a method on a server as if it were a method in your own program. It runs over HTTP/2, where one connection can stay open and carry a stream of messages both ways. That’s what keeps the line open.
- The events are binary, in Apache Avro. Not JSON. Your program decodes each one with the event’s schema. Chapter 3 measured why: the same delivery was 84 bytes in Avro against 238 in JSON.
- It’s pull-based. Salesforce’s own description: “the client requests the number of events to receive as they become available in the event bus.” More on that below.
It has its own address, api.pubsub.salesforce.com, on port 443 or 7443. If your org has to keep data in transit inside Europe, there’s a Europe endpoint too, api.deu.pubsub.salesforce.com (Pub/Sub API Endpoints (opens in a new tab), same guide, checked 2026-11-07). Chapter 2 used it as the example of a port for exactly that reason: a firewall that only expects 443 needs to know.
And it has six calls. Two to learn about a channel: GetTopic and GetSchema. Two to publish: Publish, one batch at a time with an answer for each, and PublishStream, a stream of batches for a higher rate. And two to listen: Subscribe, and ManagedSubscribe, still a Beta.
On the Line, Call by Call
Section titled “On the Line, Call by Call”Here’s what a subscriber does, the way chapter 10 walked through a bulk job:
The open line, as five calls. Steps 4 and 5 repeat for as long as it stays open.
1. Sign in. The subscriber gets an access token, the same way any program does (chapter 13), and sends it with every call, together with the org’s address and its org ID (Authentication (opens in a new tab), same guide, checked 2026-11-07).
2. Ask about the channel. GetTopic says whether the topic exists and which schema it uses. GetSchema returns that schema. Salesforce’s advice: “call GetSchema only one time and store the returned schema” (GetSchema (opens in a new tab), same guide, checked 2026-11-07).
3. Dial in. The Subscribe call opens the line. With it, the subscriber says three things: which channel, where to start, and how many events it can take right now. Where to start is module 4.
4. Hear the events. They arrive on the open line as they’re published, and the subscriber decodes each one from Avro with the schema it stored.
5. Ask for more. And here’s the part that surprises people. The subscriber said how many it could take. When it has had that many, it has to ask again, within 60 seconds, or the line closes. While it’s waiting with nothing to hear, Salesforce sends a “still here” message at least every 270 seconds (Pull Subscription and Flow Control (opens in a new tab), same guide, checked 2026-11-07).
“Tell Me Up to 100”
Section titled ““Tell Me Up to 100””Why does the subscriber have to keep asking? Think of the phone line again. The subscriber doesn’t say “tell me everything, as fast as it comes.” It says “tell me up to 100.” When it has heard those and dealt with them, it says “go on, up to 100 more.”
That’s flow control, and it protects the subscriber. If Steve Trucking’s crews close a few thousand deliveries in the last hour of the day, the subscriber isn’t flooded. Salesforce’s words: it “ensures that the client doesn’t get overwhelmed with more events that it can handle if there’s a spike in event publishing.” The most a subscriber can ask for at once is 100 (Subscribe (opens in a new tab), same guide, checked 2026-11-07). The events it hasn’t asked for yet aren’t lost. They wait on the bus.
So when I say Salesforce tells the subscriber the moment something changes, that’s true while the subscriber has asked for more. A subscriber that’s slow to ask is a subscriber that hears late.
Who Keeps Your Place
Section titled “Who Keeps Your Place”When the line drops and the subscriber calls back, it has to say where it got to. Normally, the subscriber keeps that itself: the number of the last event it handled, stored somewhere safe. Module 4 is how.
There’s a second way, still a Beta: a managed subscription. Salesforce keeps your place for you. Salesforce’s description: “Use managed event subscriptions to track the events that a subscriber client consumed and to resume a subscription from where it left off after a client disconnects.” The subscriber tells Salesforce which event it has finished with, and when it calls back with ManagedSubscribe, it picks up after that one. A managed subscription belongs to one client and can’t be shared (Managed Event Subscriptions (Beta) (opens in a new tab), same guide, checked 2026-11-07). Because it’s a Beta, check the release notes before you build a production feed on it.
A Stream, Not a Queue
Section titled “A Stream, Not a Queue”There are two kinds of thing people call an event bus, and it’s worth knowing which one you have.
Ask which one you need, not which product.
Salesforce’s event bus is a stream. Each event is kept for a while, every subscriber reads it, and each keeps its own place. A queue is different: each message goes to one worker, and when that worker’s done, the message is gone. You’d use a queue to share out work; you’d use a stream to tell many systems the same news.
The lines between products have blurred. Kafka, the best-known stream, can now do queues as well: “Kafka Queues (Share Groups) is now production-ready” (Apache Kafka 4.2 release announcement (opens in a new tab), Apache Software Foundation, 2026-02-17, checked 2026-11-07). If your team knows Kafka, the Pub/Sub API will feel familiar: the subscriber pulls, and keeps its own place. Which streams and queues sit outside Salesforce, and how they meet ours, is module 7.
Your Lab Bench
Section titled “Your Lab Bench”Try it in your Developer Edition org. Salesforce’s Python Quick Start for Pub/Sub API (opens in a new tab) builds a small subscriber; follow it with a platform event of your own.
- Define the event. A platform event called Delivery Update, with one text field, Status, as in chapter 4.
- Dial in. Run the quick start’s subscriber against
/event/Delivery_Update__e, asking for new events only. - Publish one. In the Developer Console, Execute Anonymous. In class I show it’s about five lines:
Delivery_Update__e e = new Delivery_Update__e(Status__c = 'Delivered');Database.SaveResult result = EventBus.publish(e);System.debug(result.isSuccess());- Watch it arrive in your subscriber, decoded from Avro.
- Then hang up. Stop the subscriber, publish three more, and start it again asking for new events only. What did it hear? Now you know why module 4 exists.
Test knowledge. Know that platform events are published, not inserted: they have no record ID you can query, and the only way to read them is to subscribe. Know the Pub/Sub API: gRPC over HTTP/2, events in binary Apache Avro, a pull-based subscription where the client says how many events it wants (flow control), and its methods to get a topic and schema, publish, and subscribe. Know that it supports high-volume platform events and Change Data Capture events, not PushTopic, generic or standard-volume events.
Watch it on video
Section titled “Watch it on video”In early 2024 I made two videos on this: how an event behaves differently from a record, and watching events arrive with the Streaming Monitor. The notes under the videos say what’s still right and what’s changed since.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which channel each subscriber listens to, and who’s allowed to: the subscriber signs in as an integration user, with only that access.
- How many events the subscriber asks for at a time, and how fast it asks again, so it keeps up at the busiest hour.
- Who keeps its place: the subscriber, somewhere safe, or a managed subscription, knowing it’s a Beta.
- Whether you need a stream or a queue, before you pick a product.
- The endpoint and the port, including the Europe endpoint when data in transit has to stay there, and the firewall rule that lets it through.
Explore
Section titled “Explore”- Pub/Sub API Features (opens in a new tab), Pull Subscription and Flow Control (opens in a new tab) and Pub/Sub API Endpoints (opens in a new tab): Pub/Sub API Developer Guide (checked 2026-11-07)
- Subscribe (opens in a new tab), GetTopic (opens in a new tab) and GetSchema (opens in a new tab): the same guide, the calls (checked 2026-11-07)
- Managed Event Subscriptions (Beta) (opens in a new tab) and Event Types (opens in a new tab): the same guide (checked 2026-11-07)
- Python Quick Start for Pub/Sub API (opens in a new tab): the same guide, the lab bench’s starting point (checked 2026-11-07)
- Apache Kafka 4.2 release announcement (opens in a new tab): Apache Software Foundation, queues in Kafka (checked 2026-11-07)
- Salesforce Developers, Pub/Sub API, Authentication (opens in a new tab), checked 2026-11-07.