Console journey
The user journey from modeling a control to calling its generated action and inspecting runtime evidence.
Console is where your team configures Valqio and inspects what happened after your app starts calling the runtime data plane.
For a scan of every public Console area, see the Console feature map.
Runtime setup path
- Create or select a project.
- Select the environment your app will call.
- Model the Feature, Usage Control, or Limit your application needs.
- Add its resource and verb under Use in your product.
- Attach the control to a plan or customer rule.
- Publish the environment.
- Create a server runtime API key.
- Copy the SDK environment values.
- Send an app request through the generated action.
- Inspect the transaction evidence.
A successful integration proves that real product traffic reaches Valqio and leaves inspectable evidence. You do not need to model every pricing model before integrating.
Core areas
| Console area | What it is for |
|---|---|
| Start | Guided setup, recent activity, and next action. |
| Features | Access controls with optional generated app integrations. |
| Usage controls | Meters, quotas, credits, reservations, and generated app integrations. |
| Limits | Fixed, rate, and concurrent protection with generated app integrations. |
| Plans | Packaging rules that grant controls and usage allowances. |
| Customers | Subjects that receive plans, balances, credits, and usage history. |
| Developers | API keys, SDK setup snippets, activity, and webhooks. |
| Decisions → History | Runtime decision history and evidence detail. Workbench is the adjacent Decisions tab. |
| Publish | Runtime state previews, environment publishing, and generated SDK handoff. |
| Runtime Activity | Commit, release, reservation, usage lifecycle, and diagnostics inspection. |
| Draft Invoices | Billing-sync previews and Stripe export readiness. |
| Settings | Projects, environments, members, and account billing state. |
Workbench vs app traffic
Workbench helps you test a decision shape before or during integration. App traffic is the source of truth for real runtime behavior.
Use Workbench to confirm:
- the subject exists
- the plan or customer rule is attached
- the owning control and generated action key are correct
- allow and deny paths behave as expected
Use app traffic to prove:
- the SDK has the right environment values
- the API key has the right scope
- idempotency keys are stable
- evidence links match real request IDs
- support and finance can inspect the result later
Evidence loop
Every meaningful Console journey should end at evidence:
- App calls Valqio.
- Valqio returns a decision.
- App handles allow or deny.
- Decisions → History shows the decision row.
- Decision detail explains the subject, action key, owning control, outcome, reason, request identity, and billing or usage context.
If a setup step does not lead to evidence, it is configuration, not proof.