CapaProductsFor your team
Teams & RolesNewThe right access for every person.
Bring your people into a team, give each one a role per project, and narrow any model to View, Edit entries or No access. A freelancer sees the blog. A client reviews without breaking anything. Capa enforces it everywhere they work.
Edits and publishes entries everywhere, but only reads the pricing page.
Model access- Articles
- Menus
- Events
- Pricing
- Pages
Model access applies to the admin, search and the agent surface. Your public API is governed by its keys.
Four roles. One sentence each.
Every member of a project has a role. It decides what they can do everywhere in that project until you set an exception.
- Admin
Runs the project
Everything, including members, billing and the project's settings.
- Developer
Builds the project
Models, entries, media, API keys, webhooks, cache and integrations. Everything but billing.
- Content
Writes and publishes
Creates, edits, publishes and deletes entries, uploads media and keeps categories tidy. Leaves the models alone.
- Viewer
Looks, never touches
Reads every model, entry and file. Changes nothing, which makes it the safe role for a client review.
Five levels, per model, per person.
Open a member and set any model to something other than their role. Or open a model and see everyone who can reach it.
| Level | The person can |
|---|---|
| Role default | Do whatever their role allows. Nothing is stored, so nothing changes. |
| No access | Not see it at all. It is hidden from lists, search and the API explorer. |
| View | Read its entries and fields. Change neither. |
| Edit entries | Create, edit and publish entries. Not change fields or delete entries. |
| Full | Change entries and fields, including deleting them. |
A level can lift one person on one model or hold them back from it. The project owner is never limited, so every project always has someone who can fix anything.
One team. Every project in it.
A team holds your projects and your people. Invite someone once, pick every project or just a few, and choose the role they get. Each project keeps its own models, keys and plan.
capa.app/teams/acme- Maya LindqvistEvery project, as adminOwner
- Jonah BrandtEvery project, as adminAdmin
- Ana RuizAll projects, as ContentMember
- Sam OkaforMarketing site, as ContentMember
- Marketing site4 members · its own models, keys and plan
- Store3 members · its own models, keys and plan
- Help center3 members · its own models, keys and plan
Access that stays easy to reason about.
- Invites
Copyable invite links
Invite by email or hand someone a link. They choose nothing: the role and the projects come with the invite.
- Keys
Keys with limits too
A cap_ key can read a single model, expire on a date, rotate, and refuse requests from sites you have not listed.
- No dead ends
Only buttons that work
The admin asks the API what each person may do, so nobody is shown a button the API would refuse.
- Blocked
A clear way back
A link to a hidden model explains what happened instead of showing a 404. Request access emails the project owner.
- Nav views
A sidebar per team
Share a nav view with the whole project or keep it private, so each group sees the folders it works in.
- Ownership
Hand over cleanly
Transfer a project to a new owner when an agency hands a site to its client, without moving a single entry.
Who can do what.
Can a freelancer edit one model and nothing else?
Yes. Give them the Content role and set every other model to No access. They will not see the rest in lists, search or the API explorer.
Does model access change my public API?
No. Model access governs people in the admin, search and the agent surface. Your sites read with API keys, which carry their own scopes.
What happens when someone leaves the team?
Their access to the team's projects goes with them. Anyone you also added to a project directly keeps that project.
How do agencies use it?
Make a team for the agency, a project per client, and invite each client as Content or Viewer on their own project only.
Invite everyone. Worry about no one.
Roles for the whole project, exceptions for one model, and a team to hold it all.