Basker Docs

Multi-tenancy

How the Partners API resolves an organisation and scopes its data

Every Partners API collection request is resolved to one Basker organisation, called a tenant in the API. The service adds the appropriate data constraint automatically: you do not normally include a tenant field in your filters.

Resolve the tenant

Every URL contains a tenant slug:

/partners/{version}/{tenant}/{collection}

You can override that path value with one of the tenant headers. Resolution follows this order:

PrioritySourceExample
1x-basker-tenant-id header000000000000000000000005
2x-basker-tenant-slug headerremarkable-theatre
3Tenant slug in the path/2026-02/remarkable-theatre/events

The first supplied value that resolves successfully determines the tenant. A header therefore takes precedence over a different slug in the URL.

For straightforward integrations, keep the path slug and any slug header identical:

curl -s \
  -H "Authorization: users API-Key YOUR_API_KEY" \
  -H "x-basker-tenant-slug: remarkable-theatre" \
  "https://api.basker.app/partners/2026-02/remarkable-theatre/events"

An unknown tenant returns 404. Authentication and tenant resolution are separate: a valid tenant does not make an invalid API key acceptable.

Automatic data scoping

After resolving the tenant, the API applies these rules:

  • A list or single-record read is constrained to records visible to that tenant.
  • A create request associates the new record with that tenant.
  • An update or delete succeeds only for a record owned by that tenant.
  • The internal tenant field is removed from returned records.

Tenant groups and shared data

Some organisations belong to a tenant group so they can share selected collections. Read access follows the sharing mode configured for each collection:

  • Global: every group member can read every member's records in that collection.
  • Shareable: a tenant reads its own records plus records explicitly shared with it.

REST and GraphQL reads use the same group-aware boundary. Relationships and configured custom-object fields can link to a shared record and resolve it normally.

Writes are never widened to the group. You may read and link another member's shared record, but you cannot update or delete it. A write to a readable record owned by another member returns 404.

To narrow a group-shared collection to one member, add its tenant ID to where:

curl -s -G \
  -H "Authorization: users API-Key YOUR_API_KEY" \
  --data-urlencode 'where[tenant][equals]=000000000000000000000006' \
  "https://api.basker.app/partners/2026-02/remarkable-theatre/events"

The API combines that filter with the existing group boundary, so it cannot expose records outside the group.

If an expected shared record is missing, confirm that the organisations are in the same group and that the collection is global or the record has been explicitly shared.

On this page