Registered Apps
Registered Apps give a Slab5 workspace a stable application identity. Use them to group credentials, scopes, usage, audit events, and developer-owned Vector/RAG collections under the product or integration that caused the activity.
Registered Apps are available independently of App Studio. App Studio is hidden behind a feature flag while it remains in private preview, but app identities, app-associated API keys, app usage attribution, and app audit attribution can still be used by production workspaces.
What registered apps are
A registered app describes an application that uses Slab5. It is not itself a secret and it is not a deployment.
An app identity includes:
- app name and app key
- client ID
- app type and status
- requested scopes
- allowed origins and callback URLs
- associated workspace API keys
- usage and audit attribution
- optional Vector/RAG collection ownership
The app answers "which product or integration is this?" The API key, MCP client, or grant answers "what can it do in this workspace?"
When to create an app
Create a registered app when a workspace needs to separate activity by product boundary, customer-facing integration, internal tool, agent, or environment.
Common patterns:
| Pattern | Example |
|---|---|
| Product boundary | A customer portal and an admin console each get their own app identity. |
| Internal tool | A support operations tool gets an app identity separate from the public product. |
| Agent or automation | A retrieval agent gets read-only Vector Store scopes under its own app. |
| Environment split | A staging app and production app use different app keys and API keys. |
| First-party app | A Slab5-managed app installation appears separately from developer apps. |
Do not create a new app for every API key. One app can have multiple keys, such as staging, production, and rotation keys.
App detail tabs
Click a registered app in the Slab5 console to inspect its detail view.
| Tab | Use it for |
|---|---|
| Overview | Review app identity, status, request count, Vector/RAG activity, BI usage, failures, and estimated billed usage. |
| API keys | See keys associated with the app and create a new key for that app. |
| Usage | Inspect recent usage events attributed to the app. |
| Audit log | Inspect recent audit events attributed to the app. |
| Permissions/scopes | Review requested app scopes. |
| Vector/RAG collections | See developer Vector/RAG collections owned by this app. |
| Budgets | Configure optional app-level budget metadata. |
Use app detail when answering "what did this app do, what did it cost, and which credentials are responsible?"
API keys and scopes
API keys can be associated with an app. When a key is associated with an app, Slab5 can attribute usage events, audit events, and Vector/RAG operations to that app.
Recommended setup:
- Create the app identity first.
- Review requested scopes.
- Create a key from the app detail page when possible.
- Grant only the scopes that app needs.
- Rotate keys without changing the app identity.
Use vector_store:read for retrieval-only apps. Add vector_store:write only when the app must create collections, upsert documents, delete documents, or archive collections.
Usage and audit attribution
Usage and Audit Log support app filters:
- All apps
- No app
- First-party app
- Specific app
Usage rows and audit rows show the app name/key when the event is associated with an app. Click the app name to open the app detail view.
Use app filters when debugging:
- which product drove the usage spike
- which app produced failed requests
- which key under an app is busiest
- whether an operation came from a first-party Slab5 app or a developer app
- whether an event has no app attribution and should be moved to an app-associated key
Vector and RAG ownership
RAG in a box collections are workspace-scoped. When a collection is created or mutated through an app-associated API key, Slab5 records the app ID in collection and usage metadata so the collection can appear under that app's detail view.
This keeps the operational model aligned:
- the app owns the product boundary
- the API key provides the credential
- the collection stores developer-managed knowledge
- usage and audit events show who caused the work
App ownership is optional. Workspace-level collections without an app remain valid and show as workspace-owned activity.
Budgets
App budgets are optional metadata for workspace admins who want per-app guardrails.
Budget fields include:
- monthly request cap
- monthly vector query cap
- monthly spend alert
- warn-only or hard-block mode
Current behavior: budgets are visible and configurable for app-level planning. Enforcement must be wired into the billing and request execution path before hard blocking is treated as authoritative.
Operational guidance
- Prefer one app per product, integration, or agent boundary.
- Do not share production keys across unrelated apps.
- Keep app scopes narrow and review them during every launch.
- Use app filters in Usage and Audit Log during production validation.
- Use app-owned Vector/RAG collections when a developer-facing app needs its own retrieval corpus.
- Keep workspace-only credentials for administrative automation, not customer-facing product traffic.