The same two endpoints called with your **provisioning token** run organisation-wide: the per-customer isolation filter is dropped, so retrieval spans every API account's index plus your organisation-level content in one search.

Example: a marketplace with many sellers offering one global search across the whole platform: each seller's own storefront widget queries with [their token](/docs/white-label/query-customer), while the marketplace's global search bar queries with the provisioning token.

```bash
curl "https://context-link.ai/api/v1/context?query=hand-thrown+ceramics" \
  -H "Authorization: Bearer $PROVISIONING_TOKEN"
```

```json
{ "message": "<markdown drawn from every customer's index plus shared organisation content>", "format": "markdown" }
```

[`GET /question`](/docs/white-label/ask-question) behaves the same way: swap the token and one answer is grounded across the whole fleet, citations included.

## Reads only

Writes are refused in this mode. [Saving a namespace](/docs/white-label/namespaces) with a provisioning token answers `403`:

`{ "error": "The provisioning token is read-only on this endpoint. Save with an api_account query token." }`

An organisation-wide memory write would be fleet-visible with no sensible owner, so save with a customer token instead and the note lands in exactly one customer's index.

A provisioning token stops authenticating the moment it stops being eligible: the holder is demoted from admin, or the organisation leaves the white-label plan. It does not degrade into a normal user-scoped credential.