Dashboard guide
Settings
Grab the integration code, issue or revoke API keys, and change project and organization settings.
Integration, keys, and Settings at the bottom of the sidebar are the screens that sit outside the experiment cycle. You only need to come here on the day you wire up the integration, the days you issue or revoke a key, and the days you change project settings.
What each screen handles
Section titled “What each screen handles”| Screen | Where | What it does |
|---|---|---|
| Install | The Install tab in Settings at the bottom of the sidebar | Shows integration code with your project’s keys filled in, ready to copy. It is split into three tabs: installing with your coding agent, routing your AI calls through the gateway, and tracking user outcomes |
| API Keys | The last item in the sidebar menu | Issues and revokes keys. Issued keys are listed with their name, type, last four characters, and creation date |
Until your project receives its first AI call or event, Get started at the top of the sidebar takes you straight to both screens. Get started disappears once the first call or event arrives.
The two kinds of keys
Section titled “The two kinds of keys”| Key | Where it is used | Where it lives |
|---|---|---|
Calling Key (ck-abto-…) | Every AI call going through the gateway | Server environment variables only |
Event Key (ek-abto-…) | Behavior collection in browsers and apps | Safe even if exposed |
Revocation applies immediately and apps using that key stop right away. Right after revoking, undo is available. Making separate keys per environment, such as production and CI, and telling them apart by name keeps things manageable.
The full integration walkthrough is in Get started.
Settings at the bottom of the sidebar
Section titled “Settings at the bottom of the sidebar”Settings at the very bottom of the sidebar gathers project and organization settings.
| Menu | What it does |
|---|---|
| Billing | Shows plans, payment, and invoices. Only the organization owner can manage it |
| Features and data | Sets whether request and response bodies are saved, the name, visibility, and system prompt permission of features and nodes, and provider settings |
| Install | Shows the integration code. It is the Install screen above |
Save request and response bodies
Section titled “Save request and response bodies”This is a project setting, and the default is saved.
- Saved: Request and response bodies are kept, so you can read the conversation in the request detail and load it in Testing.
- Not saved: Bodies are not kept, and only metrics such as tokens, cost, and latency are recorded. The request detail shows no conversation, and Testing cannot load it. Failed requests keep only the status code and error type, not the error message.
A change applies to later requests within a few seconds.
Features and nodes
Section titled “Features and nodes”Names, visibility, and system prompt permissions apply the same way to everyone in the project. A single-node feature is changed on its feature row, and a multi-node feature on its expanded node rows.
Visibility is a per-feature and per-node setting, and the default is shown.
- Shown: The feature or node appears in the lists where you pick one.
- Hidden: It drops out of those lists. Calls and stats are not affected.
How system prompt permission behaves is described in Routing.
Providers
Section titled “Providers”Settings for providers whose request address includes a value from your project. API keys are not stored here; they travel with each request. Today this is Google Vertex AI only. Save the Google Cloud project ID and location before choosing a Vertex AI model for a variant. The two values are saved and cleared together, and they cannot be cleared while an unarchived variant still uses them. The setup steps are in Vertex AI.