Organizations, members and keys
Everything in Zabio belongs to an organization: credits, API keys, members, projects, stored conversations and usage. Organizations belong to an account. A person can belong to several organizations. The web app and the zabio CLI manage all of this; API keys only talk to /v1.
Your account
Section titled “Your account”When you sign up you get your account and its first organization, called Default Organization, which you can rename in Settings. You are the owner of your account and of the organizations in it. Only the account’s owner creates organizations and projects.
People you invite belong only to the organizations you invite them to. They have no account of their own, cannot create organizations and get no organization of their own; someone you invited who wants their own account signs up with another email address. Someone you invited who later belongs to no organization and has no invitation waiting (they never joined, they left, or the organization was closed) gets their own account and Default Organization the next time they sign in, after the same checks as any signup. A person who has an account can also be invited into someone else’s organization.
Organizations
Section titled “Organizations”An organization has a name, a URL slug, a region (US at launch), a default language for emails (en or es) and settings. Creating one requires a verified email address and an account of your own. The creator is its owner. Transferring an organization to another owner moves it into their account, so the new owner needs an account of their own.
Balances are per organization, and the Free plan is one organization per person, so before you create a second organization the dialog suggests a project first: a project shares the organization’s balance and has its own keys and spending caps, while a new organization has its own balance and billing. If you do create one, you can move paid credit into it from an organization you own; see Billing.
Deleting an organization (owner only) closes it: API keys stop working at once, stored conversations and logged call bodies are deleted, and the encryption key that protected them is destroyed 30 days later. See Privacy.
Members and roles
Section titled “Members and roles”| Action | owner | admin | member |
|---|---|---|---|
| see the organization, members, keys, projects, usage, models, billing | yes | yes | yes |
| create API keys; change and revoke their own keys | yes | yes | yes |
| change and revoke other people’s keys; move a key to another project; rename and archive projects; edit the organization name and language | yes | yes | no |
| create projects | yes | no | no |
| invite and remove members, set the admin or member role, set member quotas, read the audit log | yes | yes | no |
| add or remove vendor keys; add credits; delete stored conversations from the web app | yes | yes | no |
| transfer ownership, change or remove an owner, delete the organization | yes | no | no |
An organization always has at least one owner. Transferring ownership makes the previous owner an admin.
Invites
Section titled “Invites”Owners and admins invite by email, choosing the organization, the role (admin or member), an optional monthly quota and, for a member, optionally the projects they work in (see Projects). The invitee receives a link in the organization’s default language. The invite is accepted while signed in with the same email address it was sent to. Inviting the same address again sends a fresh link.
Member quotas
Section titled “Member quotas”Each member may have a monthly quota in USD. It applies to the sum of spend on every API key that member created, in the calendar month, UTC. When it is reached, calls on those keys return 429 quota_exceeded with x-zabio-quota-scope: member. Quotas and spend per member are visible to owners and admins.
Projects
Section titled “Projects”Projects are an optional grouping for API keys, so usage can be read per project. A project has a name and a slug. Archiving a project hides it; its keys keep working and keep their project.
The project menu next to the organization menu shows one project or all projects. Pages show the keys, calls, usage and conversations of the project chosen there, and a new key is created in that project, or at the organization’s level under “All projects”.
A member can be limited to one or more projects, when invited or later from Members. A member limited to projects sees only those projects’ keys, calls, usage and conversations (a call and its spend count in the project they happened in, even if the key moves later), and creates keys only in them; keys at the organization’s level are not shown to them. Owners and admins always see the whole organization. Zabio enforces this on every request, not only in the web app.
On the API, a key that belongs to a project reads and changes only the conversations, responses, files and batches made with that project’s keys; a key at the organization’s level reads the whole organization. Something outside answers 404, as if it did not exist.
API keys
Section titled “API keys”A key is zb_live_ followed by 43 random letters and digits. It is shown once when created; Zabio stores only a hash and the first 8 characters after the prefix, which the dashboard shows so you can tell keys apart. Any member can create a key; a verified email is required.
| Setting | Default | Range | Effect |
|---|---|---|---|
name |
required | a label | |
project_id |
none | the project the key belongs to | |
scopes |
chat, embeddings, conversations |
subset of the three | which endpoints the key may call, changed in the key’s Edit panel; a call outside the scopes returns 403 insufficient_scope |
rpm_limit |
600 | 1 to 100,000 | requests per minute |
tpm_limit |
200,000 | 1 to 100,000,000 | tokens per minute; charged with an estimate at admission and refunded after the call |
expires_at |
never | a future time | when the key stops working: never, 7, 30 or 90 days, or a date (00:00 UTC that day). From then on calls are refused with 401 key_expired and the key shows as Expired; its creator (the owner, if the creator left) gets an email 7 days before. A new expiration brings an expired key back |
spend_limit_micros |
none | 0 or more | spend limit in micros; 429 quota_exceeded when reached, with the date it resets. The creator’s monthly member quota applies beside it |
spend_reset |
monthly |
never, daily, weekly, monthly |
when the spend limit starts again, at 00:00 UTC (weeks from Monday); never is a budget for the key’s whole life |
model_access |
everything the levels above allow | providers and models | the key’s own level of model access (see Model access) |
fallback_policy |
same_vendor |
same_vendor, cross_vendor, none |
default for zabio.fallback on explicit models |
body_logging |
off | on or off | store the request and response bodies of chat completion and embedding calls, encrypted, for the retention period |
Creating a key in the web app asks for its name, expiration and spend limit; every other setting starts at its default and is changed in the key’s Edit panel, which also holds its models. Prompt caching is not a key setting: it is automatic on every call, and a call turns it off with zabio.cache.ttl none (see cache.ttl). Every change applies on the next call. Revoking a key is immediate and idempotent; the key stays listed as revoked.
Members can change and revoke the keys they created. Owners and admins can change and revoke every key.
Body logging
Section titled “Body logging”Chat completions and embeddings store nothing by default. With body_logging on, each call’s request and response are stored encrypted under the organization’s data key and kept for the organization’s retention period. Owners and admins can read a stored body from the dashboard’s call list; each read is written to the audit log. Bodies never appear in usage exports or emails.
Model access
Section titled “Model access”Model access has four levels: your account, the organization, a project and a key. Each level narrows the one above, and a call may use only what every level allows; auto picks only among those models. By default every level allows everything the level above allows, including models added later.
At every level the same picker shows the models grouped by provider, with filters for providers, capabilities and a search. A provider’s switch allows every model of that provider, including the ones it adds later; a model’s checkbox allows exactly that model. The auto lines (auto, auto/best, auto/balanced, auto/cheap) have their own checkboxes at the top: unchecked, calls to that line are refused. When a level above turns a model off, a lower level keeps its own check: the model shows as off at that level and does not count, and it comes back when the level above turns it on again.
- Account: the account’s owner, on the Account page.
- Organization: owners and admins, on the Models page.
- Project: owners and admins, with Models on the Projects page.
- Key: whoever can edit the key, with Models on the API keys page.
A model a level refuses returns 404 model_not_found and is never picked by auto; GET /v1/models lists only what every level allows for the key. A level that allows an auto line must leave it at least one model to pick. A change at the account, the organization or a project that would leave a project or key below with no model for auto is not refused, but the picker names the projects and keys affected and asks before saving; their auto calls then answer 400 no_model_allowed, naming the level to check.
Retention
Section titled “Retention”Settings page, owners and admins: the default retention for stored conversations and logged bodies, from 1 to 365 days (30 by default). A conversation can set its own retention when it is created. See Responses API and Privacy.
Usage and calls
Section titled “Usage and calls”The dashboard shows spend, provider cost, savings, calls, tokens and latency for a period, by model, by key and by member, with a daily series. The call list shows every call’s metadata (time, key, models, tokens, cost, outcome, latency) and can be exported as CSV. Usage is also available in the CLI with zabio usage.
Audit log
Section titled “Audit log”Owners and admins can read the organization’s audit log: who created, changed or revoked a key, invited or removed a member, changed a role or quota, added credits, added or removed a vendor key, deleted a conversation, read a logged body, and so on. Each event carries the actor, the target, the time and the request id. Audit events never contain prompts, completions or secrets.
Signing in
Section titled “Signing in”Email and password (12 characters or more), Google, or a magic link sent by email. Email verification is required before an API key can be created or an organization created. Sessions can be listed and ended from Settings. The CLI signs in with a device code and receives a personal token (zbu_...) that you can list and revoke under Settings, tokens.