---
title: "Sales channels"
description: "Split one event into sales channels and allocations — partner allocations, presale access, sponsor blocks, box office — without splitting the seat count."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.seatlayer.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sales channels

A sales channel is an **allocation label** on inventory you already have. It
answers one question and no others: *which buyers are allowed to select this
seat before it sells?*

Everything else stays exactly where it was. One event, one chart, one
authoritative seat count.

## The one-minute model

Take a 1,000-seat event:

| Allocation | Seats | Who may select them |
|---|---:|---|
| Public sale | 800 | Anyone on the ordinary event page |
| Travel Agency A | 120 | Buyers carrying an Agency A buyer access session |
| Sponsor guests | 50 | Sponsor invitees |
| Box office | 30 | Your own staff selling flow |

All four audiences read the same event, the same chart geometry, and the same
inventory. Selling `A-12` through Travel Agency A makes `A-12` booked
**everywhere, immediately** — on the public page, in your reports, and in every
open buyer session. There is no reconciliation step and no second source of
truth, because there is no second inventory.

```mermaid
flowchart LR
    E["One event and chart"] --> P["Public sale"]
    E --> A["Travel Agency A"]
    E --> S["Sponsor guests"]
    E --> B["Box office"]
    P --> I["One authoritative inventory"]
    A --> I
    S --> I
    B --> I
```

## Assignment is not status

A seat's **channel** and a seat's **status** are independent. Every seat always
has both.

| | |
|---|---|
| **Status** | `free`, `held`, `booked`, `blocked` — what is physically true |
| **Channel** | Public sale, or exactly one private channel — who may select it |

Assigning a seat to a channel never changes its status. A free seat in a private
channel is still free; it is simply invisible to buyers who are not eligible for
that channel. This is why assignment is safe to run on a live, selling event.

It is also why a channel is not a way to take a seat off sale. If nobody should
sell it, block it.

## What a channel is not

The five things that get confused with channels, and the feature that actually
does each job:

| What you want | Use |
|---|---|
| Nobody may sell this seat | [Block](/server-api/blocking) |
| Reserve it during checkout | [Hold](/server-api/holds) |
| Open or close a section for everyone | [Section availability](/server-api/inventory) |
| Change price or visual treatment | [Category and pricing](/designer/accessibility-and-pricing) |
| Let only a particular audience select it | **Sales channel** |

## One seat, one channel

A seat belongs to Public sale or to exactly one private channel. Never two.

Overlapping membership was considered and rejected: it makes "how many seats
does the sponsor have?" unanswerable, and it makes every allocation edit a
question about precedence. The property you actually want — *this buyer may see
several allocations* — belongs on the buyer, not on the seat. A
[buyer access session](/server-api/buyer-access-sessions) can name several
channels at once, so a sponsor who is also an agency customer sees both
allocations without either seat being in two places.

That keeps every allocation total exact and every seat's answer to "whose is
this?" a single value.

## Public sale is a real allocation, not an absence

Seats not assigned to a private channel are **Public sale**. It behaves like any
other allocation in reports and in the API — it has counts, it has sell-through,
and inventory moves in and out of it — with two differences:

- it is the default, so every event you already have is entirely Public sale and
  stays that way until you say otherwise. There is no migration;
- it needs no grant. A buyer with no session at all sees Public sale, exactly as
  today.

In the API, Public sale is the reserved channel id `public`, and a seat on
public sale reports `channelId: null`. A buyer access session must say
[`includePublic`](/server-api/buyer-access-sessions) explicitly — there is no
default, in either direction.

## A channel id is not authorization

This is the part worth reading twice.

A channel id is a **label**, not a key. Sending one from a browser grants
nothing, and a browser cannot select private inventory by naming a channel it
guessed, was told, or read out of your page source. The server derives what a
caller may select from the credential the caller presents, and ignores any
channel the client claims.

What actually grants access:

- a [buyer access session](/server-api/buyer-access-sessions) (`bse_…`), minted
  by your backend for one buyer, one event, one origin, and a named set of
  channels;
- a [hosted access link](/server-api/channels), which a buyer exchanges for one
  of those sessions;
- a secret key that explicitly names the channel it is acting for — see the
  behavior change on [booking](/server-api/booking).

An unauthorized buyer does not receive a private seat's real state at all.
Private inventory reads as one flat unavailable state, whatever is really
happening inside it, and a public map receives no updates from activity it is
not allowed to observe.

## Where to go next

- [Channels API reference](/server-api/channels) — create, assign, pause, archive
- [Buyer access sessions](/server-api/buyer-access-sessions) — mint and revoke buyer scope
- [Private and partner sales](/integrations/private-and-partner-sales) — the end-to-end tutorial
- [Reports](/server-api/reports) — allocation and sale attribution per channel

Source: https://docs.seatlayer.io/platform/sales-channels/index.mdx