Sales flow

From the catalog to delivering the key and to support β€” the end-to-end integration.

This is the path a store or a bot follows to sell and deliver keys without anyone opening the panel.

Build the storefront

Fetch the products with List products and cache the list for a few minutes. Show only the ones with available: true, with the durations from plans.

Record the sale with a code

When the customer pays, create an Idempotency-Key (a UUID) and store it with the order, before calling the API. That code is what guarantees the sale is never charged twice.

Generate the key

Call Generate keys with the chosen product_id, quantity and days.

  • It worked: store generation_id, and for each key its user_id and key_code.
  • Network error, timeout or 500: retry with the same Idempotency-Key. If the first one had worked, you get the same keys without a new charge.
  • 402: balance too low. Nothing was charged; tell the customer delivery will be delayed and buy credits.
  • 422: the product became unavailable or the duration does not exist. Do not retry: check the storefront.

Deliver it to the customer

Send the key_code to the customer. The key stays at status: DISPONIVEL until they activate it.

Handle support

  • "I changed my PC": call Reset HWID with the key's user_id.
  • "My key does not work": look the key up with List your keys and user_ids[] β€” check status, hwid_status and seconds_remaining.

Reconcile

In the statement, each generation shows up with type: key_generation and reference_id equal to the generation_id. That is how each credit spent links to the sale that caused it.

Get notified instead of asking

With webhooks, your system receives a notification for every key generated, HWID reset or balance change β€” including the ones made in the panel.

On this page