Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.userepo.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Bearer tokens

Every Repo API request requires an Authorization header: 
Authorization: Bearer repo_live_a1b2c3...
Keys start with the repo_ prefix and are issued from the console’s Developers tab. The full secret is shown once at creation time — Repo stores only a SHA-256 hash, so a lost key cannot be recovered. Mint a new one and rotate.

​
Two ways to mint keys

MethodWhoWhen
Console UIHumans with a Supabase loginFirst key for an org, manual rotation
POST /v1/api-keysAn existing key with the admin actionProgrammatic key creation from CI/CD or your own admin tool
The bootstrapping pattern: mint your first admin key in the console, store it in your secrets manager, then use the API to issue scoped agent keys.

​
Key shape

{
  "id": "uuid",
  "name": "support-agent-prod",
  "prefix": "repo_a1b2",
  "actorType": "agent",
  "allowedActions": ["search", "context", "ask", "memory:read"],
  "allowedProviders": ["slack", "notion"],
  "lastUsedAt": "2026-05-30T20:14:00Z",
  "createdAt": "2026-05-23T18:33:00Z"
}

​
Actor types

  • agent — Default. An AI agent making programmatic requests.
  • application — A traditional application or backend service.
  • admin — Capable of minting other keys (admin action grants this).
The actor type is metadata only — it doesn’t change what the key can do (that’s controlled by allowedActions). It’s there for audit + observability.

​
Actions

Every action is a discrete permission a key may carry. Pass the full set when creating a key; Repo enforces them at the route level.
ActionEndpoint(s)Purpose
admin/v1/api-keys (CRUD), /v1/maintenance/*Mint/revoke keys, run maintenance jobs
searchPOST /v1/searchVector search across the org’s memory
contextPOST /v1/contextFull Context Contract (search + citations + exclusions)
askPOST /v1/askGrounded answer generation with citations
memory:readGET /v1/memory-canvasGraph view of entities + relationships
sources:readGET /v1/sourcesList connectors
sources:writePATCH /v1/sources/:idModify connector settings (e.g. Slack channel allowlist)
sync:readGET /v1/sync-runsView sync run history
sync:writePOST /v1/sync-runsQueue a sync run
ingestPOST /v1/ingestPush source documents directly (no connector required)

​
Provider scopes

allowedProviders is an optional whitelist of provider IDs the key may retrieve from. Pass null for no restriction (the key sees everything the org has connected); pass an array to scope it down. 
{
  "allowedProviders": ["slack", "notion"]
}
Available providers: slack, google_drive, notion, gmail. When /v1/search or /v1/context runs against a key with provider scopes, hits from excluded providers are filtered out server-side before any data leaves Repo — the key cannot bypass the scope by inspecting the response.

​
Rate limits

Each (api_key, action) pair has a per-minute budget — default 60 req/min, configurable per-deployment via API_RATE_LIMIT_PER_MIN. Over-limit calls return 429 with headers: 
HTTP/1.1 429 Too Many Requests
Retry-After: 47
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 2026-05-30T20:15:00Z
See Rate limits for tier-specific budgets and burst behavior.

​
Revocation

curl -X DELETE https://api.userepo.com/v1/api-keys/{id} \
  -H "Authorization: Bearer repo_admin_key"
Revoked keys take effect immediately (no cache). The revoke endpoint refuses to delete the key currently authenticating the request — you can’t lock yourself out by accident.

​
Console keys vs. API keys

The console uses Supabase Auth tokens (the Authorization: Bearer eyJ... from a logged-in human). API keys are for agents. Repo treats them as different actor types in the audit log so you can always distinguish “Gabriel did X” from “the support agent did X”. Console endpoints are namespaced under /v1/console/* and never accept API keys. Agent endpoints are namespaced under /v1/* (no console prefix) and only accept API keys.