request_id & Duplicate Protection

request_id is your unique reference for a recharge (your order number, cart id, UUID…). It makes POST /likee/recharge idempotent.

#Rules

• Required on every recharge. 1–100 characters: letters, digits, _ . - :.
• Unique per API key (enforced by a database unique constraint on api_key_id + request_id).
• The same request_id sent again — seconds or days later — returns the existing order and never creates a second recharge or a second debit.

HTTP 200
{
  "success": true,
  "data": {
    "order_id": "BST-LKE-8F72A19X",
    "request_id": "ORDER-CLIENT-10001",
    "platform": "likee",
    "status": "processing",
    "duplicate": true,
    "…": "…"
  }
}

A first-time creation answers 201; a replay answers 200 with "duplicate": true.

#Why this matters

Network timeouts happen. Without idempotency you would have to guess whether the first request reached us. With request_id you simply retry the identical request:

1. Persist request_id in your database before the first attempt.
2. Send the recharge.
3. On timeout / 5xx / SERVICE_UNAVAILABLE, retry with the same request_id (use exponential backoff).
4. Whatever happens, at most one order exists for that request_id.

#Boostigo order_id

Boostigo generates its own public id for every order: BST-LKE-8F72A19X (BST = Boostigo, LKE = Likee, 8 random characters). Store both ids:

Use order_id for GET /orders/{order_id} and for support requests.