Skip to main content
Organization endpoints operate on your Limitless workspace. They use Admin API keys beginning with lka_. Inference keys begin with lk_ and cannot call these routes. Use workspaces and members for teammate invitations, roles, workspace switching and workspace settings. Those controls use your signed-in console session.

Manage projects in the console

Open Projects to create or rename a project, set its monthly spending cap, or archive it. Owners and admins can make changes; members can view projects and caps. The default project remains available as the console fallback and cannot be archived there. Use the sidebar project switcher to choose the project for API keys, Home, Activity and Playground. Your selection is remembered for your account. Switching projects clears the temporary conversation and stops an active stream. All projects share the workspace’s prepaid balance; their individual caps apply alongside the organization cap. When a project cap rejects a Playground request, Check project cap opens Projects so you can review its limit. The prompt remains available to retry. Archiving permanently disables new requests for that project. Show archived projects lists archived metadata; prior usage remains available in the Administration API’s reports. These console actions use your signed-in session, so you do not need to create an Admin API key unless you want to automate management.

Create the first Admin API key

A workspace owner or admin opens Admin API keys in the console at /app/admin-api-keys, chooses the required permissions, and creates a key. Store the returned secret in your server’s secret manager. List and retrieve operations return a redacted value.
LIMITLESS_BASE_URL ends in /v1. A key belongs to one organization; request parameters cannot switch it into another organization’s resources.

Permission scopes

Customer keys can be scoped to models:read, inference:write, and credits:read. Omitting their permissions during creation grants all three. An insufficient scope returns 403.

Create a project and customer key

Use the returned project ID in the next request:
The key’s value appears on creation and an identical idempotent creation replay within 24 hours. Do not log the response. Metadata reads cannot recover the secret. Project, customer-key, Admin API key, and policy creation require an Idempotency-Key of 8–200 printable characters. Reuse a key only for the same operation and body; changed requests conflict. This protection applies to administrative mutations, not inference generations. Archived projects reject new inference with their keys; prior usage remains recorded.

Reports and balance

GET /organization/balance returns decimal USD strings for available_usd, reserved_usd, and owed_usd. A customer key with credits:read can instead use GET /credits for its organization’s available balance and lifetime usage. Usage and cost reports require start_time in Unix seconds, with optional end_time. Usage buckets accept 1m, 1h, or 1d; cost buckets are daily. Filter with project_ids, api_key_ids, and, for usage, models. Group usage by project_id, api_key_id, or model; group costs by project_id, api_key_id, or line_item. List endpoints return has_more and resource cursors. Reports return next_page; send it as page while retaining the original filters and time window. Report totals reflect recorded usage. Unresolved reservations remain separate from settled cost.

Spending caps

Set positive monthly USD caps through POST /organization/spend_limit or POST /organization/projects/{project_id}/spend_limit, with amount_usd. Read with GET and remove with DELETE. Both cap levels and the shared wallet apply to admission. A missing cap returns 404 on retrieval. alert_threshold_basis_points stores threshold metadata; this release does not send alert notifications. See limits for reservation and calendar-month behavior.