Skip to main content

​
Overview

The Members system adds multi-user access to a tenant. Each tenant starts with a single owner (created during provisioning). The owner can invite additional members, assign roles, and control which domains each member can access. Members are separate from contacts. A member is someone who has API access to the tenant — an employee, a contractor, an agent. They authenticate with their own API key and are subject to access policies that limit what they can read or write.

​
Data Model

​
Entities

EntityDescription
MemberA user within a tenant. Has a name, email, role, and active status.
Access PolicyA per-domain permission grant for a member (e.g., “read-only on contacts”).
InvitationA pending invite with a claim code. Once claimed, creates a member + API key.

​
Roles

Every member has a role field:
RoleDescription
ownerFull access. Created during tenant provisioning. Cannot be deactivated.
adminCan manage members, invitations, and access policies.
memberStandard access, subject to access policies.

​
Key Concepts

​
Access policies

Access policies control what a member can do per domain. Each policy has:
  • domain — The target domain: contacts, crm, tasks, calendar, notes, or admin
  • access_level — One of: none, read, write, admin
  • resource_filter — Optional JSON filter to restrict access to specific resources (e.g., only certain projects)
Policies are set as a complete replacement — PUT /api/v1/members/{id}/access replaces all policies for that member. An admin cannot grant more access than they themselves hold.

​
Invitations

Instead of creating members directly (which is available but requires you to manage API key distribution), the invitation flow handles onboarding:
  1. Admin creates an invitation with pre-configured access policies
  2. The system returns a one-time claim code
  3. The invitee calls POST /api/v1/invitations/claim with the code (no auth required)
  4. They receive their member record, API key, and access policies
Invitations expire (default: 7 days) and can be revoked before claiming.

​
Member API keys

Each member gets their own API key. The key is linked to the member, so audit logs show which member performed each action. Admins can create additional keys for a member via POST /api/v1/members/{id}/keys.

​
Deactivation

Members are deactivated (soft disabled), not deleted. Deactivating a member sets is_active = false — their API keys stop working immediately. The owner member cannot be deactivated.

​
API Endpoints

See the API Reference for the full endpoint list with request/response details.

​
Examples

​
Invite a new team member

# Create an invitation with contacts read + tasks write access
curl -X POST https://api.backside.app/api/v1/invitations \
  -H "Authorization: Bearer bsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alex Chen",
    "email": "[email protected]",
    "role": "member",
    "access": [
      { "domain": "contacts", "access_level": "read" },
      { "domain": "tasks", "access_level": "write" }
    ]
  }'

​
Claim an invitation (no auth required)

curl -X POST https://api.backside.app/api/v1/invitations/claim \
  -H "Content-Type: application/json" \
  -d '{
    "code": "bki_a7f3k9m2p4x1..."
  }'
# Response includes: member, api_key (show once), access_policies

​
Check your own member info

curl https://api.backside.app/api/v1/members/me \
  -H "Authorization: Bearer bsk_live_..."