# A channel is a name. Nothing to provision.

A channel exists as soon as something subscribes to it and disappears when the last connection leaves. Its name picks the type: public for anything a visitor may read, private for anything scoped to a customer, presence for a room with a roster, and a cache prefix for state a late joiner needs immediately.

## The prefix is the configuration.

## There is no channel registry to keep in step.

Channels are the addressing model of the Bird Realtime API. You never create one: you subscribe to a name, and the first three characters of that name tell the edge how to treat it. A name with no prefix is public. private- asks your backend to approve each subscription. presence- does the same and attaches an identity. private-encrypted- seals the payload with a key Bird never holds. Names take up to 164 characters, are case-sensitive, and are the one part of a channel you should think about carefully, because a public name is visible to anyone holding the app key.

## Five kinds of room.

Same protocol, same client, same publish call. The name is what differs.

## One publish, up to a hundred channels.

Publishing is an ordinary REST call from your server. Name up to 100 channels in one request and the edge fans the event out to all of them. A batch carries up to 10 unrelated events, each to its own channel. Pass the acting client's connection id as exclude_connection_id and the tab that already applied the change locally is skipped. Ask for connection or member counts with include and the response tells you the state of each channel at publish time. Retry with the same idempotency key and you will not deliver twice.

## Clients can talk to each other directly.

A typing indicator or a cursor position does not need to visit your API. Enable client events on the app and a subscribed client can trigger an event named client-something straight to the others in the channel, capped at 10 per second per connection. They only work on private and presence channels, which is deliberate: the app key ships in your page, so authorization is what makes a client trustworthy enough to broadcast. Treat what arrives as a signal, never as authoritative state, because the edge does not validate the payload.

## What a channel will and will not remember.

A publish returns once the edge has accepted the event. Delivery is asynchronous, there is no per-client receipt, and a client that drops mid-delivery will not be sent the event again on reconnect. That is the honest contract, and it is why durable state belongs in your database and events announce that it changed. Caps are the same on every plan: 100 channels per publish, 10 events per batch, 10 KB per payload, 164-character channel names.

## Go deeper in the docs.

The Realtime overview defines channels, members, and connections in one page. Publishing events covers broadcast, batch, and exclusion, cache channels explains the replay, and querying channel state is the server-side read for occupancy and counts.

## Subscribe to a name and start publishing.

Create an app, ship the public key in your client, and keep the secret on your server. The free plan covers 100 concurrent connections.