A project groups the eval suites of one codebase. An API key belongs to exactly one
project, and runs reported with it are filed there.
1. Create the project
From the sidebar’s +, or Projects → New project. Name it after the application, not
the agent — one Laravel app with six agents is one project.
2. Create a key
New projects show their connection steps immediately, including a key created for you:
The full key is shown once, when it is created. Only a sha256 hash is stored, so we
genuinely cannot show it to you again — not “won’t”. If you lose it, create another.
3. Add it to your environment
That is the whole configuration on the hosted service. VIZRA_CLOUD_ENDPOINT defaults to
https://vizra.ai/api/v1/runs and only needs setting if you are pointing at a
self-hosted instance.
4. Run your evals
The run finishes, reports, and appears in the project. Nothing else changes — the same run
is still recorded locally, and the gate still decides pass or fail exactly as before. See
what gets reported.
Managing keys
Each key shows its project, when it was created, whether it has ever been used, and its
expiry. “Never used” is usually the answer to “why aren’t my runs showing up”.
Expiry
Choose Never, 30 days, 90 days or a year when creating a key. An expired key
stops being accepted at ingest; runs still record locally.
Rotate, don’t revoke
Rotate creates a replacement and keeps the old key working for 7 days, so you can
deploy the new one everywhere before the old one stops. Rotation never extends an expiry
that was already sooner than the grace period.
Revoke stops the key immediately. Worth knowing what that looks like from the other
side: a rejected upload never fails a build, so anything still using the key goes quiet
rather than erroring — you notice by the missing runs, not by a red pipeline.
Give CI its own key, named for the pipeline. When you rotate it you know exactly what has
to be redeployed, and revoking it doesn’t stop anyone’s laptop reporting.