Four things in your product are also facts Connect holds: what a customer
bought, what that entitles them to, who on their side may do what, and what
happens to their data when they leave.

Each of these pages describes one of them. They are worth reading before the
[API reference](/docs/api), because every endpoint there assumes one of these
models and none of them explain it.

| Page | The question it answers |
|---|---|
| **[Plans, pricing and free tiers](/docs/concepts/plans)** | What a customer bought, and what changes when they switch tier or cadence |
| **[Capabilities](/docs/concepts/capabilities)** | What that purchase entitles them to, and what they can buy on top of it |
| **[Authorization](/docs/concepts/authorization)** | Who inside their workspace may do what — and why Connect never enforces it for you |
| **[Deletion policy](/docs/concepts/deletion-policy)** | What you keep when they leave, and who answers for it |

## The line that runs through all four

**Connect answers questions about the customer; your code answers questions
about your product.**

That single rule decides where nearly everything belongs, and it is the one
worth internalising before the details:

| Question | Whose answer |
|---|---|
| Is this person signed in, and to which workspace? | Connect |
| Does their plan include this feature? | Connect |
| Have they used up this cycle's add-on balance? | Connect |
| Are they an admin on your application? | Connect resolves it; **you enforce it** |
| May they archive *this particular* campaign? | You |
| What does "archived" mean? | You |

The third and fourth rows are the pair people get wrong. Connect resolves a
member's permissions for your `client_id` — flattening their role, the implicit
`admin` synthesis and any custom workspace role into one list — and hands you
the list. It never refuses your API call on your behalf, because it does not
know which of your operations needs which permission. Keeping a second copy of
the *resolution* is duplication; doing the *enforcement* yourself is the job.

## Two shapes that surprise people

**A plan row is a tier and a price point at once.** Stripe and Paddle split
these in two (a Product and a Price); Connect keeps them in one row and joins
the halves with `planGroup`. "Growth monthly" and "Growth annual" are two rows
declaring the same group. Pair them with `planGroup`, never by name — a name is
neither unique nor stable across a rename. See
[Plans](/docs/concepts/plans).

**A change of billing cadence is not an upgrade or a downgrade.** It is a third
kind of plan change with its own settlement: the running cycle closes, what is
left of it is valued and credited, and a fresh cycle is billed and re-anchored.
Treating it as an upgrade prorates a delta across two cadences that is negative
either way, floors to zero, and settles the whole switch for nothing. See
[Plans](/docs/concepts/plans).

## Where to go next

Once these four are clear, [Building the UI](/docs/ui) is the same models
rendered — the gates in that section are each one of these concepts with a
component wrapped round it.