# Workspaces, members & roles A **workspace** is your team. It owns the projects, the sending credentials, the API keys and the people — everything that is not per-project lives here. Workspace URLs are the first segment of the dashboard path: `///`. ## Roles Everyone in a workspace can do the day-to-day work. What the roles separate is the ability to change *who can act* and *what mail leaves through* — plus the handful of operations that cannot be undone. | | Owner | Admin | Member | | --- | :---: | :---: | :---: | | Read and write contacts, lists, templates, campaigns, automations | ✓ | ✓ | ✓ | | Send campaigns and transactional mail from the dashboard | ✓ | ✓ | ✓ | | Read beacons, revenue and reviews | ✓ | ✓ | ✓ | | Create a project | ✓ | ✓ | ✓ | | Invite and remove members | ✓ | ✓ | — | | Add, rotate or remove a sending credential | ✓ | ✓ | — | | Choose which credential a project sends through | ✓ | ✓ | — | | Issue and revoke API keys | ✓ | ✓ | — | | Delete a project | ✓ | ✓ | — | | Delete the workspace | ✓ | — | — | Three of those lines are the same authority wearing different hats. Holding a sending credential, pointing a project at one, and issuing an API key with `campaigns:send` are all ways to put mail on the wire under your domain — so they are gated together rather than one being a way around the others. Note the second row: **a plain member can send email.** A dashboard session implies every scope, because a human in the dashboard is already bounded by what the UI offers. If you need someone who genuinely cannot send, do not give them a session — give them an agent API key, which cannot. ## Inviting a teammate Invite from **Settings → Members**. The invitation goes out by email with a link, and it expires — an old invitation in an archive is not a way in. What happens next depends on whether they already have a Pharos account: - **They do** — they sign in and the invitation is accepted. - **They don't** — they create one from the invitation link. This works even while self-serve signup is closed: an invited address is allowed to sign up, which is the whole point of an invitation. The address is fixed to the one that was invited. An invitation is for one address. Signing in as somebody else and following the link tells you so rather than quietly joining the wrong account. Cancelling a pending invitation revokes the link immediately. ## Removing a member Removing someone ends their access to every project in the workspace at once. It does not touch anything they created — their campaigns, templates and contacts belong to the project, not to them. It also does not revoke API keys. A key is a workspace credential, not a personal one: it keeps working after the person who created it leaves, which is usually what you want for a production integration and never what you want for someone who left under a cloud. **Rotate keys when someone with admin access leaves.** ## Deleting a project Owner or admin, and it is irreversible. Everything the project ever had — contacts, lists, templates, campaigns, automations, the entire send history, and stored files — goes with it. ```bash curl -X DELETE "https://pharosbase.com/api/projects?slug=acme-app&confirm=acme-app" ``` The `confirm` parameter must equal the project slug. That is not ceremony: it means a mis-fired request carrying a stale identifier cannot delete anything, because the caller has to have named the specific project twice. Stored files are purged before the rows are deleted, in that order deliberately — the other way round leaves objects in storage with nothing left pointing at them. If a file cannot be removed, the response says so in a `warning` rather than swallowing it, because that leftover is something a human has to finish. An audit record is written **before** the delete, since afterwards there is no project left to attribute it to. ## Deleting a workspace Owner only — not admin — and it takes every project in it. ```bash curl -X DELETE "https://pharosbase.com/api/organizations?confirm=acme" ``` Same confirmation rule, against the workspace slug. ## Plans Every workspace currently runs on the default plan. The tiers shown on the pricing page and the billing tab are **placeholder pricing**: nothing enforces a limit yet, and no code path refuses work because a workspace is over quota. Worth knowing what the shape is *not*, though. Pharos does not meter email volume, because Pharos does not send on its own credentials — you bring your own provider and pay them directly, so charging for delivery would be a markup on something Pharos does not supply. What a plan scales with is how much the workspace manages: projects, contacts, and people. See [Sending & deliverability](/docs/sending-providers).