Teams and roles

A project is not a lonely account. Add people under Teams and each one gets a seat on that project with a role that decides what the seat can touch. Membership is per project: someone can be an owner on one app, a contributor on another and a viewer on a third, and the Teams screen shows the seat matrix across every project in the workspace. There is no limit on how many people you add, on any plan, and nobody is billed per person.

The five roles

Role	What the seat can do
owner	Everything: deploy, database and secrets; manage domains and mail domains, API keys and deploy hooks; delete an inbox and its mail; change team settings, roles and memberships; pick alert recipients; export the audit log; transfer or delete the project.
member	The build work plus the keys to it: deploys, database, env var values, API keys, camplax dev tokens, project and git settings, logs, monitors, errors. Can invite members, contributors and viewers.
contributor	The build work without the keys: deploys, database, logs, flags, cron, monitors, errors. Sees env var names, never values; cannot make API keys, webhook secrets or an inbox's mail-app login, change project settings or integrations, or invite anyone. Code a contributor deploys still runs with the app's env, so this keeps secrets out of their hands in the console — it is not isolation from someone who can ship code.
billing	Money, nothing else: plan, card, credits and invoices. Cannot deploy or read the vault.
viewer	Look, never touch. Can open every page any seat can read; every request that would change something is refused.

In API terms the routes check a handful of buckets: owner alone for destructive and team-admin actions, owner + member for secrets, keys and people, owner + member + contributor for build surfaces, and owner + billing for billing. A viewer is refused on every non-GET request centrally — not route by route — so a write route that forgot to name its roles still fails closed. An API key gets the same check with its maker's seat, so it can never do more than the person who made it. Lee's tools do not act for viewers or contributors yet, and a viewer cannot use MCP at all.

Email invites

Invite by email address and role. The invite email links to the console's Join page and is valid for 7 days; accepting requires signing in with the invited address — and that address must be verified — so a forwarded link does not grant a seat to the wrong person.

• Resend mints a fresh token and restarts the 7-day clock — use it when the first mail expired or went to spam. One invite can be resent once every 10 minutes, counted from when it was first sent.
• Revoke kills a pending invite before it is accepted.
• Only an owner can grant the owner or billing roles; a member can invite members, contributors and viewers.
• Seats have no per-user fee on any plan; invite emails are limited. A project can send 50 invite emails a day, one person 200 a day across all their projects, and one address gets at most 3 Camplax invites a day. Over the project or personal limit nothing is sent and the answer (429) says which limit it was and when it frees up; over the address limit the invite is still saved and its link comes back to share by hand. Need more? The invite dialog's Request more asks Camplax to raise the project's limit or your own (POST /v1/projects/:slug/teams/invite-limit-requests with { "scope": "project" | "account", "reason" }); Camplax reviews it and emails you the answer, and an approval applies at once. The per-address limit protects the person receiving the mail and is not raised.
• Removing someone (or moving them below member) also revokes the API keys and camplax dev tokens they made on the project, revokes the invites they sent that are still pending, and rotates the team's invite link so the one they saw stops working.

Invite links and domain lock

For a team where inviting one address at a time does not scale, the project has an invite link (copy it from Teams → Settings; it opens the console's Join page). Enable it in team settings and anyone signed in with a verified email who opens it joins as a member — which is why only owners and members are ever shown the link. Rotate the token and every old link dies at once — that is the off-switch when a link leaks. Neither token is kept in Camplax's database as itself: an emailed invite's token is stored only as a SHA-256 hash, and the invite link as a hash plus an encrypted copy used to show it to owners and members.

Two settings control who may join at all:

• Allowed domains — a list like acme.com; only matching email addresses can be invited or use the link.
• Domain lock — when on, the allow-list is enforced (invites to other domains come back blocked; the join link refuses them). With the lock on and an empty list, nothing gets in — the list is the gate, not a suggestion.

Access requests

Someone with a Camplax account can ask for a seat through the API: POST /v1/access-requests with the project's slug and an optional note. (The old console had an Ask for access form on Projects; the current console does not yet, so the endpoint is the way in.) The answer is always the same — "If that project exists, its owners will see your request" — so it cannot be used to find out which slugs exist.

Owners get an email when someone asks (who asked, and a link to Teams — never the requester's note), and see waiting requests at the top of Teams → Members; pick a role (viewer is preselected) and let the person in, or deny. An approval can grant member, contributor, billing or viewer — never owner; ownership moves only by invite or transfer. One person can have 10 open requests at a time, and after a deny or a withdraw they cannot ask the same project again for 24 hours. Your own list shows every request you made, by the name you typed, whether or not that project exists. An approval needs the requester's email to be verified, and honours the team's domain lock the same way invites do.

The audit log and its export

Teams → Audit log records who did what: API keys, env vars (names, never values), invites, joins, role changes, removals, team settings, access requests and decisions, transfers, and a member deleting their account. Owners, members and contributors can read it.

Owners can Export CSV. The export is paged on the server — at most 1,000 rows a request, with the cursor for the next page in the X-Next-Before response header — and the console joins the pages (up to 50,000 rows) into one file. Cells a spreadsheet would run as formulas (=, +, -, @) are prefixed with '. Starting an export is itself an audit event.

Account → Audit (GET /v1/account/audit) shows the same events across every project you can audit. Deleting a project keeps its audit events there for its owner — marked with the project's old address, for your plan's history window (7, 14 or 30 days) — so who did what, and who deleted it, is still on record after the project is gone. Its members lose them with their seats. Changes Camplax support makes to your account itself, such as putting it on a plan, show there too, as "Camplax support". Deleting your account removes them.

Transferring a project

An owner can hand a project to another Camplax account from Settings → Transfer: the recipient's email, the project's slug typed back, and your password (an account with no password proves itself by having signed in within the last ten minutes instead), plus the code from your authenticator app when two-factor is on. The recipient gets an email and sees the project at the top of Account; nothing changes until they accept. A transfer expires after 7 days, and there is one pending transfer per project at most.

On accept, the recipient becomes the owner and you stay on as a member — remove yourself afterwards if you want to leave. The project's GitHub link is removed, because it used your GitHub installation; the new owner connects their own. Any API key you made with the manage scope is revoked in the same step (a manage key acts as the owner); other keys keep working, and the new owner is shown them to review. The whole hand-over happens at once or not at all.

A transfer is refused, with a reason, when it would move money: the project has a Stripe account connected for payments, or the recipient's plan has no room for another project (or they have no plan). Settle those first. Prepaid credits never block a transfer: they belong to your account, not the project, and stay with you. It is also refused while the project has previews running on your account's shared preview database — delete them first; previews the new owner opens land on their own.

Deleting your account

Account → Danger zone deletes the account for good. Type the account's email address and your password (or, with no password on the account, sign in again within ten minutes), plus the code from your authenticator app when two-factor is on. Two things stop it first, and the panel lists them before you type anything:

• A project you own that other people work on. It would disappear from under them — transfer it, or remove them, first.
• A plan that is still billing. Cancel it in Billing first.

Then every project you own goes through the same teardown a single project delete does — app, database, files, domains, mail domains and inboxes, secrets and keys — and only when the last one is gone is the account itself removed. A project delete keeps one final copy of each database for 30 days, in case it was a mistake, and then deletes it. Every other browser session, CLI login and MCP grant ends the moment you confirm; the browser you used stays signed in to show progress and is signed out at the end. Projects you are a seat on (not the owner) keep running without you: your seat is removed, any API key you made there is revoked, and your address is taken out of their audit log. Credits in a project you own go with that project, exactly as a project delete does. A notice goes to the address once it is done.

The rules that protect you

• The last owner cannot be demoted or removed. Demoting or deleting the final owner seat returns last_owner — a project always keeps someone who can administer it.
• The project's owner keeps their seat. Demoting or removing the person who owns the project returns owner_of_record, even when there are other owners. Ownership moves by transfer instead.
• You cannot remove yourself. Another owner does it.
• Removing a member revokes their keys. The API keys and camplax dev tokens they minted for the project are revoked in the same step; the environment tokens Camplax injected into the app keep working. Camplax also checks the maker's seat every time a key is used, so a key whose maker no longer holds an owner or member seat is refused on every route at once — even one minted in the same moment they were removed.
• Invites to domains outside an active lock are recorded as blocked, not sent — you can see who was turned away.
• All team endpoints are session-only: project API keys, CLI logins and MCP grants cannot manage membership, transfer a project or delete an account.
• A request for another project's access requests, audit export or transfer answers 404, never 403 — existence is not probeable.

The API surface

Endpoint	What it does	Who
GET /v1/projects/:slug/teams	Members, pending invites, role counts, invite-link state	any seat
GET /v1/projects/:slug/teams/audit	One page of the audit log (limit ≤ 100, before cursor)	owner/member/contributor
GET /v1/projects/:slug/teams/audit/export	CSV, ≤ 1,000 rows; next page cursor in X-Next-Before	owner
PATCH /v1/projects/:slug/teams/settings	domainLock, allowedDomains, inviteLinkEnabled	owner
POST /v1/projects/:slug/teams/invite-link/rotate	New link token; old links stop working	owner
POST /v1/projects/:slug/teams/invites	{ "emails": […], "role" } — email invites	owner/member
POST /v1/invites/accept	{ "token" } — accept an emailed invite; the token names the project, session email must match	the invitee
POST /v1/projects/:slug/teams/invites/:id/resend	New token + fresh 7 days; once per 10 minutes	owner/member
GET /v1/projects/:slug/teams/invite-limits	Today's invite-email limits for this project and you, and your latest request for more	owner/member
POST /v1/projects/:slug/teams/invite-limit-requests	{ "scope", "reason", "requestedPerDay"? } — ask Camplax for a higher limit	owner/member
DELETE /v1/projects/:slug/teams/invites/:id	Revoke a pending invite	owner/member
PATCH /v1/projects/:slug/teams/members/:id	Change a role	owner
DELETE /v1/projects/:slug/teams/members/:id	Remove a seat	owner
POST /v1/invites/join	{ "token" } — join through the invite link, as member	any verified user the lock allows
POST /v1/access-requests	{ "slug", "message"? } — always 202	any signed-in user
GET /v1/access-requests · DELETE /v1/access-requests/:id	Your own requests; withdraw one	the requester
GET /v1/projects/:slug/teams/access-requests	Waiting requests	owner
POST /v1/projects/:slug/teams/access-requests/:id/approve	{ "role" } — member, contributor, billing or viewer	owner
POST /v1/projects/:slug/teams/access-requests/:id/deny	Turn a request down	owner
GET · POST /v1/projects/:slug/transfer	See or start ({ "email", "confirmation", "password"? }) a transfer	owner
DELETE /v1/projects/:slug/transfer/:id	Cancel a pending transfer	owner
GET /v1/account/transfers	Projects waiting for your address	you
POST /v1/account/transfers/:id/accept · /decline	Take the project, or turn it down	the addressee
GET /v1/account/deletion	What deleting would remove, what blocks it, which proof applies	you
POST /v1/account/deletion	{ "confirmation": "<your email>", "password"? } — starts it	you