Concepts
The four models you have to share with Connect — plans, capabilities, authorization and deletion — and where the boundary between us runs.
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, 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 | What a customer bought, and what changes when they switch tier or cadence |
| Capabilities | What that purchase entitles them to, and what they can buy on top of it |
| Authorization | Who inside their workspace may do what — and why Connect never enforces it for you |
| 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.
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.
Where to go next
Once these four are clear, Building the UI is the same models rendered — the gates in that section are each one of these concepts with a component wrapped round it.
MCP
Register your MCP endpoint with Connect, and its assistant can answer questions from inside your product - as the member asking, with their own permissions.
Plans, pricing and free tiers
What a plan is in Connect, why a monthly and an annual price are two rows, and what happens when a customer changes tier or cadence.