Example platform journeys

These journeys show how the hosted Console, data plane, SDK, evidence, and billing sync fit together. They are product patterns, not setup scripts.

AI generation credits

Use this path when every generation spends credits or counts toward a quota.

1. Model a generation Usage Control with credits, quota, or a plan allowance.
2. Add Generations / Run under Use in your product.
3. Publish the environment.
4. Install the Node SDK from npm.
5. Call Valqio before starting generation.
6. Run generation only when the decision allows it.
7. Store request ID, idempotency key, reason code, and reservation ID when present.
8. Inspect decision evidence and runtime activity in Console.

Use reservations when the generation is expensive, asynchronous, or likely to fail after it starts. Commit after the output is successfully created. Release when the job fails before completion.

API marketplace calls

Use this path when a customer action triggers a third-party API call that has cost, rate, or resale impact.

1. Model a Usage Control for the external call.
2. Set the unit to match the commercial event, such as request, lookup, enrichment, or report.
3. Add the provider-facing resource and verb under Use in your product.
4. Call the generated action before calling the external provider.
5. Use a stable idempotency key for provider retries.
6. If the provider call succeeds, commit or record usage.
7. If the provider call fails before value is delivered, release the reservation.
8. Use evidence to answer support and finance questions later.

Valqio should decide before your product creates provider cost. The billing provider can invoice later from the recorded usage outcome.

Team seat or workspace limits

Use this path when a workspace can invite seats, run exports, or access plan-gated actions.

1. Model the Feature, Usage Control, or Limit.
2. Add the resource and verb under Use in your product.
3. Attach the control to a plan or customer policy.
4. Publish the environment.
5. Use the integration's side-effect-free test to preview allowed and denied outcomes.
6. Call the generated action from the server route that performs the work.
7. Return a product-specific response when denied, such as upgrade, quota reached, or contact sales.
8. Inspect evidence when a customer asks why the work was blocked.

This keeps pricing enforcement out of scattered product code while preserving a clear customer experience.

What all journeys have in common

Every public integration should prove:

• Valqio was called before the product action ran.
• The subject, action, quantity, request ID, and idempotency key were stable.
• The app handled allow and deny outcomes deliberately.
• Evidence exists for support, finance, analytics, and audits.
• Billing sync, when enabled, starts from runtime evidence rather than app guesses.