Realtime Messaging: Pub/Sub & Presence

# Realtime messaging. Keep everyone in the moment.

Keep booking screens, order updates and shared application views in sync. Publish an event once and let connected customers see the change.

[Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Frealtime)

[Talk to sales](/demo?product=realtime)

BIRD / REALTIME

Illustrative experience

01

Publish an update

02

Reach the subscribers

03

Recover a connection

Replay ↺

Resume

Pause

Your server / Published update

Example · no request is made

channel: private-studio

event: studio-visits.updated

event: job.updated

record: FN–1042

record: JOB–42

Requested

Confirmed

Queued · 0%

Rendering · 50%

Complete · 100%

Customer view needs recovery

Two current application views

Customer app

STUDIO VISIT / FN–1042

RENDER JOB / JOB–42

SUBSCRIPTION REFUSED

### Friday, 14:00

### Studio film export

### Private view unavailable

Alex Lee · Two people

Preview render · authored example

Sign in with an eligible account.

Requested Confirmed Queued · 0% Rendering · 50% Complete · 100% Access denied · stale

Access denied Disconnected · stale Subscription required Subscribed · stale Connected · current

Studio dashboard

STUDIO VISIT / FN–1042

RENDER JOB / JOB–42

### Friday, 14:00

### Studio film export

Alex Lee · Two people

Preview render · authored example

Requested Confirmed Queued · 0% Rendering · 50% Complete · 100%

Example content and data. Explore the workflow below; nothing is sent or changed in a live account.

Companies that trust Bird across their communications.

- [Airwallex](/customers/airwallex)
- Uber
- [Zillow](/customers/zillow)
- [Glovo](/customers/glovo)
- PayPal
- Adobe

[Read Bird customer stories](/customers)

BIRD REALTIME

A connection with context.

DOCUMENTED OPERATING BEHAVIOR

## A connection can recover. Your state must, too.

The client reconnects and resubscribes after an unexpected interruption. Private channels need fresh authorization; your application then fetches current business state. Reconnection does not replay missed events.

[Read the connection lifecycle ↗](/docs/guides/realtime/connection-lifecycle)

Source checked 18 September 2026. Local examples show the method, not measured latency, a live service result or guaranteed delivery. Confirm current account access and region.

REALTIME / TRY IT YOURSELF

## Connections change. Keep the state understandable.

Disconnect an example subscriber, update the booking, then reconnect and refresh from your application. See the difference between an event and authoritative state.

Interactive examples require JavaScript. Product details, setup choices, and guides remain available below.

Application case

Private studio booking

Private rendering progress

Save & publish ↗

Disconnect subscriber

Reauthorize & subscribe

Fetch application state

Inspect the result below after each action. [Read the result and next step ↗](#rt-state)

Refuse private access

Restore eligible session

Fail state read

Repeat older notification

Inspect the result below after each action. [Read the result and next step ↗](#rt-state)

STUDIO DASHBOARD / APPLICATION RECORD

STUDIO VISIT / FN–1042

RENDER JOB / JOB–42

### Friday, 14:00

### Studio film export

Illustrative application record

Requested Confirmed Queued · 0% Rendering · 50% Complete · 100%

CUSTOMER APP / SUBSCRIBED VIEW

STUDIO VISIT / FN–1042

RENDER JOB / JOB–42

SUBSCRIPTION REFUSED

### Friday, 14:00

### Studio film export

### Private view unavailable

Illustrative application record

Requested Confirmed Queued · 0% Rendering · 50% Complete · 100% Access denied · stale

Access denied

Disconnected · stale

Subscription required

Subscribed · stale

Connected · current

No event published

Two authorized views begin at revision 0. Choose an action; no request is made.

Connection lost. The customer view is stale; the studio can continue saving changes.

New connection → fresh channel authorization → subscription succeeded. Fetch current application state next; no missed events were replayed.

403 · subscription refused. Sign in with an eligible account before retrying; the public app key grants no private access.

403 · application refused this private subscriber. Its private view is cleared. No subscription or state read is permitted.

Eligible application session restored. Reauthorize and subscribe before fetching state.

State read blocked. Restore the connection and an authorized subscription first.

Application state read failed. Keep the stale label; retry this read, not the business mutation.

Repeated or older application revision ignored. This application uses its own revision policy; Bird does not promise ordered or exactly-once delivery.

Illustrative only · no publish, account action or live connection. Application revisions are our example policy. HTTP 200 means edge acceptance, not client receipt. [Work the recovery procedure ↗](/docs/guides/realtime/overview)

WHAT IT MEANS FOR YOUR CUSTOMER

## When something changes, everyone can move with it.

Bring shared activity, presence, and application progress into the same moment. Publish from your server and keep the connected experience useful for the people watching.

01 / Shared activity

### The whole team sees the update.

Publish the application change to subscribed views so a shared workspace can stay current.

02 / Presence

### Know who is here.

Use presence to show connected members in the experience your application controls.

03 / Application progress

### Make the work understandable.

Let your server publish progress into a live interface while your application remains responsible for the underlying job.

FIND YOUR WAY IN

## Publish from your server. Authorize in your app.

Inside the connected application

### Choose Realtime.

Publish events to active subscribers, with private-channel authorisation and state recovery designed into your application.

[Publish your first event ↗](/docs/get-started/send-your-first-realtime-event)

Bring someone back to the app

### Explore Push.

Bring customers back to a useful screen with a notification. Use Push with their permission and a registered device.

[Compare the notification path ↗](/push-notifications)

### The details behind your setup

#### Public, private, presence

Choose the channel model for the data. Private and presence subscriptions require application authorization.

#### Recover the working view

An event is a notification, not your database. Reconcile from your authoritative application state after a connection gap.

#### Client & server together

Keep publishing credentials on your server. Use a supported client SDK for subscriptions and connection events.

READY WHEN YOU ARE

## One event. Two views, together.

[Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Frealtime)

[Talk to sales](/demo?product=realtime)

01

[Prepare server and client ↗ Confirm account access and region, then use the same app, channel and event.](/docs/get-started/send-your-first-realtime-event)

02

[Authorise the connection ↗ Keep private and presence access in your application.](/products/realtime/security)

03

[Recover the current view ↗ Reconcile from application state after a connection gap.](/docs/guides/realtime/overview)

BUILD WITH REALTIME

## Make the change. Share the moment.

Publish only from your server. This example uses fictional order data on orders and presence-lobby. Public channels do not protect private data; presence subscriptions need application authorization. Acceptance is separate from client receipt.

Prepare an app and its keys with CLI or MCP, then connect your Realtime client. Publishing, subscriptions and recovery run through the SDK and WebSocket connection.

[Create a Realtime app ↗](/docs/cli/reference/realtime-apps-create)

[Create an app key ↗](/docs/cli/reference/realtime-apps-keys-create)

[Publish and inspect events ↗](/docs/guides/realtime/publishing-events)

[Connect an MCP client ↗](/ai/mcp-client)

[Open the implementation guide →](/products/realtime/getting-started)

**Node.js**: `npm install @messagebird/sdk`

```typescript
const result = await bird.realtime.publish("rap_01krdgeqcxet5s7t44vh8rt9mg", {
  event: "order.updated",
  channels: ["orders", "presence-lobby"],
  data: { order_id: "ord_123", status: "shipped" },
});
console.log(result.data?.length); // one entry per channel
```

Examples: [TypeScript](/es-es/realtime-messaging-api.ts.md) · [Python](/es-es/realtime-messaging-api.py.md) · [Go](/es-es/realtime-messaging-api.go.md) · [PHP](/es-es/realtime-messaging-api.php.md) · [cURL](/es-es/realtime-messaging-api.curl.md)

Use the same app and region as the server. This browser example listens to order.updated on the public orders channel; keep private customer data behind your application authorization and fetch current state after reconnection.

**TypeScript**: `Browser client`

File: `app.ts`

Run: `Browser; public app key`

```typescript
import { BirdRealtime } from "@messagebird/realtime";

const bird = new BirdRealtime({ appKey: APP_KEY, region: "us1" });
const orders = bird.subscribe("orders");
orders.bind("order.updated", (data) => {
  renderOrder(data);
});
```

Examples: [TypeScript](/es-es/realtime-messaging-api.ts.md)

THE COMPLETE BIRD PLATFORM

## Live in the app. Connected beyond it.

Use Realtime while a customer is present, then Email or messaging for useful updates outside the session.

STUDIO-VISITS.UPDATED

Booking confirmed

↓

Customer app · Studio dashboard

Authorised subscribers

01

### Realtime This step

The studio sees Alex’s booking change in its application.

[Your studio visit. All in one place. fieldnotes. BOOKING FN–1042 Your studio visit. All in one place. Alex Lee · Friday, 14:00 Clay workshop · One guest View your booking ↗](/products/email)

02

### [Email ↗](/products/email)

The server sends the updated confirmation.

[Today · 9:41 Your studio visit is tomorrow at 14:00. Booking FN–1042. Thank you. See you there!](/products/sms)

03

### [SMS ↗](/products/sms)

A consented reminder uses the same booking record.

BUILD YOUR BIRD SETUP

A useful next connection.

[Push ↗ Reach them beyond the app Discuss notification platforms and current access.](/push-notifications)

[Agent mailboxes ↗ An agent’s shared workspace Bring mailbox activity into your own application view.](/agent-mailboxes)

[SMS ↗ A timely update elsewhere Add a message when the customer needs one.](/products/sms)

[Email analytics ↗ A wider operational picture Understand the email side of your customer workflow.](/email-analytics)

Show a booking update in the app with Realtime, then send a durable confirmation with Email. Use SMS or WhatsApp for moments that need to reach beyond an open application.

[Plan your complete Bird setup ↗](/demo?product=realtime)

LEARN / BUILD / OPERATE

## Go further with Realtime.

[FIELD GUIDE Publish from your server. Authorize in your app. A practical path through setup, implementation, and the choices that matter. Read the field guide →](/guides/recover-a-realtime-application-connection)

[Explore all resources Quickstarts, implementation guides, comparisons and migration.](/realtime/resources)

[01 Prepare the first event Check the complete publisher/subscriber path. ↗](/products/realtime/getting-started)

[02 Choose channel access Public, private, presence and latest-event cache. ↗](/products/realtime/channels)

[03 Recover application state Reauthorize, resubscribe and fetch current business state. ↗](/docs/guides/realtime/connection-lifecycle)

[04 Represent presence Member identities, tabs and observed departures. ↗](/products/realtime/presence)

[05 Operate channel notifications Durable acceptance and channel-state reconciliation. ↗](/products/realtime/webhooks)

REALTIME / YOUR APPLICATION

## Size the live experience. Keep room for what is next.

Start with the free preview: 100 concurrent connections and 200,000 messages per day across all apps in your workspace. Compare Realtime pricing for larger workloads, including your publications, fan-out and peak connections.

[Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Frealtime)

[Talk to sales](/demo?product=realtime)

[Explore Realtime pricing ↗](/products/realtime/pricing)

YOUR REALTIME SETUP

Events + connections

Scope the workload and its peak activity.

Application traffic

Model event frequency and connected subscribers.

Access model

Choose public, private, or presence channels.

Beyond the app

Add Email and messaging where the customer journey needs them.

## Realtime, answered.

A FEW USEFUL ANSWERS

### Is Realtime the same as Push?

Realtime connects active application clients to live events. Push addresses notification experiences through device or browser notification services. They solve different parts of the journey.

### Who authorizes access to private channels?

Your application must decide which users can access each private channel. Keep authorization and business rules on your trusted server.

### What happens during a disconnected period?

The client can miss updates. Reconnect and reconcile from your application’s current state; an event stream is not the authoritative database.

### Can I expose the publishing secret in the browser?

No. Keep publishing credentials server-side. Clients use the app key and supported subscription authorization for the channel type.

### How do I get started or speak to sales?

Start with a Bird account and follow the setup path on this page. Our sales team can help with migration, volume, or a wider product mix. Start now or talk to sales.

YOUR NEXT CONNECTION

## Make the next update a shared moment.

[Start now](/dashboard/signup?returnTo=%2Fdashboard%2Fw%2Frealtime)

[Talk to sales](/demo?product=realtime)

[Explore the whole Bird platform ↗](/products)



## Related resources

- [Build your first integration](/learn/paths/integration) (course)

[Get an implementation brief](/learn/workspace?topic=realtime)
