Security
Best practices
What saves you trouble with balance, tokens and keys.
Tokens
| Do | Why |
|---|---|
| Use the token only on the server. | On the customer's computer, anyone could read the token and spend your balance. |
| One token per system, named after where it lives. | If one leaks, you delete only that one. |
| Check only the permissions you need. | A leaked read-only token does not spend credits. |
| Prefer tokens with an expiration. | A forgotten token stops working on its own. |
Generating keys
| Do | Why |
|---|---|
Create one Idempotency-Key per sale and store it with the sale. | Retrying after a network error returns the same keys, without charging again. |
Check available before generating. | An unavailable product does not generate keys. |
Send days with one of the durations in plans. | A duration the product does not have is rejected. |
Store generation_id, user_id and key_code. | They link the statement and support to the keys you delivered. |
Calls
| Do | Why |
|---|---|
| Use a timeout of about 30 seconds. | Without it, a stuck connection holds your system. |
On a network error or 500, retry with the same Idempotency-Key. | The API recognizes the retry and does not generate again. |
On 429, wait the seconds in Retry-After. | Insisting before that only causes more 429. |
| Cache the product list for a few minutes. | The catalog rarely changes, and every call counts toward the limit. |
Look up specific keys with user_ids[]. | It is faster than fetching the whole list. |
Every call is logged on our side, with date, IP and result.