1. Configure the feature counter
Enable an export feature on the authorization policy and give it a limit of 500 per month. Decide whether exceeding the limit is blocked or allowed under that feature's configured overage rule.
Feature counters belong to the customer's license. They are separate from the vendor workspace's device and API subscription quotas. Daily and monthly feature periods use UTC; a monthly period resets at the start of the next UTC calendar month.
2. Open one SDK client
Install the SDK for your language through the SDK documentation and open it with product.json and the customer's key. The nine SDKs expose the same metered business workflow; this example shows the Go call inside an existing error-returning application function.
For a normal entitlement use RunFeature. For a limited usage action use RunMeteredFeature. A successful local entitlement check does not prove that online quota remains.
3. Wrap the business action
Persist a unique job ID before calling the SDK. Reuse that ID when retrying the same business task. The SDK first reserves one use, then invokes the callback, then confirms successful work or cancels a known business failure.
// client was opened once at application startup.
// jobID comes from your durable business task record.
jobID := os.Getenv("LICENTIVO_OPERATION_ID")
if jobID == "" {
return fmt.Errorf("persist a unique task ID before exporting")
}
err := client.RunMeteredFeature(ctx, "export", 1, jobID, func() error {
// Return success only after the output has been saved.
return os.WriteFile("licensed-report.txt", []byte("Metered export\n"), 0600)
})
if err != nil {
return err
}4. Recover interrupted work
When a task is already recorded as successful, retrying its ID lets the SDK settle pending accounting without rerunning its callback. If the process died while the business callback was running, the SDK cannot know whether the external operation finished.
Inspect your saved business result. Call ResolveMeteredFeature(ctx, jobID, true) for confirmed success, or false for confirmed failure. This resolves accounting only. Never blindly repeat a payment, file delivery or other irreversible action.
The default reservation lasts 15 minutes and is bounded by a UTC period reset. Finish and settle before expiry; do not use the simple wrapper for a job that may outlive its reservation. A canceled business task needs a new ID if the customer deliberately starts a new attempt.
5. Verify counter behavior
- Start with a small test limit. A successful export should increase used by one.
- Make the callback return an error before completing work: its reservation should be canceled.
- Retry a successfully recorded job ID and confirm the callback is not repeated.
- Exhaust a blocked quota and confirm the callback does not run. Show a clear message with the next reset time.
- Simulate an interrupted task on your test environment and resolve it from the durable business record.
Common mistakes
Counter operations require connectivity. An offline cached license alone does not authorize an offline reserve or commit. Do not silently turn a denied metered action into an unmetered action.
A direct Consume call deducts immediately. Use the metered callback when usage should count only after business success. A network failure after work completes is an accounting recovery problem; do not assume the work failed.
Stable task IDs and SDK journals help retries; they do not replace your business transaction or durable result storage. Keep both the business result and the SDK's private cache available during recovery.