OreCloud

Keys & environments

Environment-bound API keys, scopes, and double-gated text access.

Tenancy lives in the credential

API keys are minted bound to one environment. Every org gets the fixed production/testing pair. Client() reads the key and binds itself to that environment, so the same code serves testing and production by swapping the key. Nothing about tenancy is hardcoded in application code:

from lodedb.cloud import Client

client = Client()   # org + environment come from ORECLOUD_TOKEN

Key kinds

  • Secret keys (ore_sk_…): server-side use. Scopes chosen at mint.
  • Publishable keys (ore_pk_…): safe for lower-trust surfaces, they can rank results but can never read stored text.
  • Personal tokens: your own login (via lodedb cloud login), unscoped to an environment; pass org=/environment= explicitly.

Mint and revoke via the console, or:

lodedb cloud tokens mint --kind secret --scope write --scope read:search
lodedb cloud tokens list
lodedb cloud tokens revoke <token-id>

The secret is shown once at mint.

Text access is double-gated

Reading stored text back (get, context_block, include_text=True) requires both:

  1. the key to carry the read:text scope, and
  2. the store to have its expose_text flag on (explicit store create defaults it off; auto-provisioned memory stores enable it).

A key alone is never enough. The store owner's flag has to agree. This is enforced server-side, not a client convention. Telemetry and audit logs are metrics-only (counts, ids, latency), never document text, queries, or embeddings.

On this page