One Key, One Partition
Every API key in Tupshar owns a separate logical partition identified by its owner_key_id. All documents, tags, properties, links, and search indexes belong to exactly one key. A key can only see its own data — there is no cross-key query or cross-key search.
This is the isolation boundary: API key = data partition. No exceptions.
Multiple Keys per User
A single Clerk account can hold up to 25 API keys. Each key is its own isolated partition, so you can use different keys to separate projects, environments, or clients without any data leaking between them.
For example:
tupk_project_a…— documents for Project Atupk_project_b…— documents for Project Btupk_staging…— test data that never mixes with production
Deleting (revoking) a key permanently blocks access to its partition — the key can no longer authenticate, so its documents become unreachable. Revocation does not erase the underlying document rows; if you need the data actually removed, delete the documents first.
Key Scopes
Each key is issued with one of three scopes:
| Scope | Capabilities |
|---|---|
read | Query and retrieve documents only |
write | Read plus create, update, and delete documents |
admin | Write plus manage API keys for the account |
Narrowing scope for keys used in automated pipelines reduces blast radius if a key is leaked.
What Is Not Shared
- Documents are never visible across keys.
- Search indexes are per-key; a query on key A does not touch key B's index.
- Quotas are per-key (document count, storage bytes).
No Cross-Key Sharing
There is currently no mechanism to share a document from one key's partition with another key. If multiple processes need access to the same documents, they must use the same API key.
See HTTP API for key management endpoints.