Generated actions

A generated action is the application-facing entry point for a Valqio control. It is not a separate Console resource. Open the Feature, Usage Control, or Limit, then add a resource and verb under Use in your product.

For example, Videos / Render derives:

Action key: videos.render
SDK path:   customer.actions.videos.render

The owning control determines the lifecycle:

There is no operation picker, backing-resource selector, or editable SDK method name. The integration already belongs to its control, and its resource and verb form the stable published action key.

Everyday work

Use run() when product work happens in the same process:

return customer.actions.videos.render.run(
  {
    quantity: 1,
    idempotencyKey: `render:${jobId}`,
  },
  async ({ transactionId }) => renderVideo({ transactionId }),
)

Valqio decides before the callback, invokes it only after a successful claim, and settles according to the owning control. A denial never runs the callback. An uncertain commit never causes successful work to be released.

Queued work

Use begin(), claim(), and the lifecycle-specific settlement methods when a queue or service boundary separates the request from the worker. Store the returned action transaction ID with the job. The application supplies one idempotency key; Valqio owns private phase keys.

App responsibility

Your app still owns:

• choosing the subject and stable product-attempt identity
• running product work only through the generated action boundary
• mapping typed denial errors to product language
• persisting the action transaction ID with queued jobs
• storing any local business records it needs

The boundary is simple: call Valqio before the billable action. Billing can invoice later; Valqio decides whether the work should run and records what happened.