Skip to main content

When you need sub-entities

Your org has multiple semi-independent business units and you want each to have its own phone numbers, agents, and settings, all managed from one LumisReach seat. Common cases:
  • Healthcare network. One parent entity, many clinic locations, each with its own outbound numbers.
  • Franchise. One brand, many franchisees.
  • Agency. One agency, many end-client workspaces.
Every sub-entity is a Team with parent_organization_id pointing to your umbrella org. Members can belong to the umbrella, a specific sub-entity, or both. Phone numbers, calls, reputation tracking, and brand registration are all sub-entity-scoped.

What sub-entities share vs. own

The reputation-enrollment service walks the hierarchy automatically: when a phone on a sub-entity is provisioned, it looks for a team-level enterprise first, then the parent org’s enterprise, then falls back to the Lumis Labs umbrella. So you register once at the umbrella, and every sub-entity’s numbers are covered.

API key scopes

Two scopes matter for sub-entities:
  • Org-scoped keyauth.teamId = umbrella org id. Sees every sub-entity under the umbrella. Use for HQ engineering or internal tools.
  • Sub-entity-scoped keyauth.teamId = sub-entity id. Sees only that sub-entity’s resources (phone numbers, calls, contacts). Use when issuing keys to per-location ops or to a vendor managing a single location.
A sub-entity-scoped key reading caller-trust endpoints (enterprise / brand / reputation) sees the parent umbrella’s registration — your one Branded Calling registration covers every child automatically. To issue sub-entity-scoped keys: as the umbrella admin, create them via the Settings → API Keys UI with teamId = subEntityId, or have a LumisReach admin issue one on your behalf from the carrier-registrations admin panel.

Endpoints

All sub-entity endpoints require:
  • An umbrella-org-scoped API key, OR
  • A user-scoped API key where the user is ADMIN / OWNER of exactly one organization.
Required scopes: sub_entities:read, sub_entities:write.

Create a sub-entity

The new sub-entity inherits the parent’s HIPAA posture by default. The umbrella user who issued the request is auto-added as OWNER.

List sub-entities

Paginated. Pass cursor=<id> from meta.cursor to fetch the next page.

Get one

Update

Setting hipaa_enabled: true requires the umbrella org to have an executed BAA on file. If the flag won’t flip, email support@lumisreach.com.

Worked example: onboard a new location end-to-end

Tenant isolation guarantees

A sub-entity-scoped key:
  • Reads: filters every resource (phone numbers, calls, contacts, messages, reputation) to teamId = subEntityId only. Never sees the umbrella’s or sibling sub-entities’ records.
  • Writes: created resources are tagged with teamId = subEntityId so they’re visible only within that sub-entity.
  • Caller-trust reads (enterprise, brand, reputation): walk up to the parent umbrella’s registration. Read-only — the sub-entity can see the brand it’s calling under, but cannot modify it. To edit, use an umbrella-scoped key.
If a sub-entity needs its own brand (separate legal entity, distinct CNAM), register it via POST /v1/caller-trust/enterprise using a key scoped to that sub-entity, then sign + submit via POST /v1/caller-trust/enterprise/sign-and-submit.

HIPAA inheritance

Creating a sub-entity under a HIPAA-enabled parent auto-inherits the flag. A sub-entity can opt out by setting hipaa_enabled: false, but that’s unusual — leave it on if the parent has an executed BAA. The parent’s BAA covers all sub-entities under it — no separate BAA per child. The hipaa_enabled flag on each sub-entity controls whether the runtime HIPAA gates apply to that specific child. See HIPAA & BAA coverage for what this flag gates and how to request a BAA.