Excluding event recipients
When a client's own action causes a publish, that client usually applied the change locally already. Sending the event back to it makes the change land twice: once optimistically, once from the event. The result is a flicker, or a duplicated item.
Pass the acting client's connection id and the edge delivers to every subscriber except that one connection.
Code example
await bird.realtime.publish(appId, {
event: "message.created",
channels: ["presence-room-1"],
data: { body: "hello" },
exclude_connection_id: "26896.319537",
});Getting the connection id to your server
The client reads its own id from the connection and sends it with the request that triggers the change:
Code example
const bird = new BirdRealtime({ appKey: "your-app-key", region: "us1" });
await fetch("/messages", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({
body: "hello",
connection_id: bird.connection.connectionId,
}),
});bird.connection.connectionId is null until the connection is established, and it changes when the client reconnects. Read it at the moment you make the request rather than caching it at startup.
Your handler then passes it straight through to exclude_connection_id. Treat it as untrusted input: it decides only who does not receive an event, so a wrong value costs one client an update rather than exposing anything.
What exactly is excluded
Only that one connection. The same person's other tabs are separate connections and still receive the event, which is usually what you want, because those tabs did not apply the change locally.
Excluding a connection id that is not subscribed, or no longer exists, is not an error. The publish delivers normally to everyone else.
When to skip it instead
Excluding is an optimisation for optimistic UIs. If your client applies changes only when an event arrives, do not exclude anything: the acting client needs the event like everybody else, and skipping it leaves that tab stale until the next update.
Next steps
- Publishing events covers the rest of the publish payload, including batching and broadcasting.
- Presence channels explain why one member can hold several connections.
- Publish an event is the full reference for the request.