Data plane
How the hosted runtime data plane answers app requests after Console configuration is published.
The data plane is the hosted runtime service your application calls from server-side code. It answers whether product work should run and records evidence for the decision.
What the data plane receives
A runtime request usually includes:
- project and environment
- server runtime API key
- subject, usually a customer account or workspace
- product action, meter, limit, or generated helper alias
- quantity
- request ID
- idempotency key
- optional context, such as workspace, feature, endpoint, model, or job ID
Do not call consuming runtime methods from browser code with a server key. Keep enforcement calls on your backend, worker, or serverless function.
Evaluate, enforce, reserve
Use the operation that matches the work:
| Need | Use | Result |
|---|---|---|
| Preview access or read non-consuming config. | Evaluate. | Returns current flags, configs, or access state without consuming usage. |
| Count usage immediately. | Enforce. | Allows or denies and records the usage decision. |
| Hold value while work runs. | Reserve, then commit or release. | Prevents overspend while async or failure-prone work is in progress. |
Runtime state
Console is the control plane. When you publish an environment, Valqio prepares runtime state for the data plane. Your app calls the hosted data plane URL from Console, not the Console UI itself.
Runtime calls should be treated as part of the product action path. If Valqio denies, do not run the costly work. If Valqio allows, keep the request ID, idempotency key, reason code, and any reservation ID with your request logs so support can trace what happened in Console.
Failure behavior
Design every consuming call as retryable:
- Send a stable idempotency key for each product attempt.
- Reuse the same key when retrying the same attempt.
- Use a different key for a new product attempt.
- Commit a reservation only after your app has durably completed the work.
- Release a reservation when work fails before completion.
This lets Valqio avoid double counting repeated requests and explain delayed, retried, or partially completed work.