Teams & projects

ReachBell has three levels. Your organization is the account your team shares. Inside it live one or more projects — one per app or site. Each project owns its subscribers, credentials, and campaigns. This page covers how the structure fits together and how to bring your team into it.

Organization  →  Projects  →  Subscribers
   (your team)     (per app)     (devices / contacts)

Organizations

An organization is the top-level account and the boundary everything else sits inside. When you sign up, ReachBell creates one for you and makes you its Owner. It holds your team roster, your plan and billing, and every project you create.

Data never crosses the org boundary: a project, and the subscribers under it, belong to exactly one organization, and only that org's members can see them.

Projects

A project is a self-contained environment for one app or website — its own subscribers, its own channel credentials, its own campaigns and analytics. Spin up a new project whenever you have a distinct audience to keep separate: a second app, a staging site, a different brand.

Create and manage them from the dashboard (or via the API):

Method & path	What it does
`POST /projects`	Create a project in your organization.
`GET /projects`	List the projects in your organization.
`GET /projects/:id`	Fetch one project.

Each project has its own API key (an rb_live_… key). The key is scoped to that project: it can only read and write that project's subscribers and campaigns, so a leaked or rotated key never reaches across your other projects. Keep one key per project and store it as a secret — see Authentication.

Sandbox projects

Mark a project as a sandbox to test end to end without sending anything or running up usage. With sandbox on, every send is logged so you can watch it flow through, but nothing is delivered to a real device or inbox, and nothing is billed. It's the safe place to wire up the SDK, fire test campaigns, and shake out an automation before pointing real traffic at a live project. Toggle it in the project's settings.

Use a dedicated sandbox project for development and a separate live project for production, each with its own API key. That keeps test traffic out of your real analytics and out of your bill.

Inviting teammates

Add people from your organization's Members settings. An invite goes out by email with a link that's good for 7 days; when the teammate accepts, they join with the role you picked.

The flow, if you're driving it through the API:

Method & path	What it does
`POST /organizations/:orgId/invites`	Invite an email address with a role.
`GET /organizations/:orgId/invites`	List pending invites.
`DELETE /organizations/:orgId/invites/:inviteId`	Revoke a pending invite.
`POST /organizations/accept-invite`	Accept an invite (the invitee, from the link).

The invite is tied to the email address it was sent to — it can only be accepted by someone signed in with that address, so an intercepted link is useless to anyone else.

Once people are in, manage them from the same place:

Method & path	What it does
`GET /organizations/:orgId/members`	List the team roster.
`PATCH /organizations/:orgId/members/:userId`	Change a member's role.
`DELETE /organizations/:orgId/members/:userId`	Remove a member.

Roles

Every member holds one of three roles. They gate what you can change — reading is open to the whole team.

Role	Can do
Owner	Everything, including billing, deleting the org, and managing other owners.
Admin	Manage projects and team: create projects, edit settings, upload credentials, invite and manage members. Can't act on owners.
Member	Day-to-day work — build and send campaigns, automations, and segments.

A few rules the system enforces:

Only an Owner can grant or change the Owner role, and an organization must always keep at least one Owner — you can't remove or demote the last one.
Admins can invite and manage members, but can't change, demote, or remove an Owner.
Inviting teammates, creating projects, and editing project settings or credentials require Owner or Admin. Members and below can't change the team or project configuration.

Granting read-only access. ReachBell's role guard supports a read-only tier — a member with a viewer-level role can see the dashboard but is blocked from any write. If your plan exposes a Viewer role in the invite dialog, use it for stakeholders who need the analytics but shouldn't touch campaigns.