Recharge Flow
What happens, in order, when you call POST /likee/recharge. If any step fails, the request is rejected with the error shown and no balance is debited.
| # | Boostigo checks | Error |
|---|---|---|
| 1 | Authorization header present |
INVALID_API_KEY |
| 2 | API key exists | INVALID_API_KEY |
| 3 | API key active | API_KEY_DISABLED |
| 4 | Store active | STORE_DISABLED |
| 5 | Likee enabled for the key | PLATFORM_NOT_ENABLED |
| 6 | Client IP allowed | IP_NOT_ALLOWED |
| 7 | Rate limit | RATE_LIMIT_EXCEEDED |
| 8 | Body is a JSON object | INVALID_JSON |
| 9 | request_id present & well-formed |
INVALID_REQUEST_ID |
| 10 | request_id not used before by this key |
→ returns existing order (duplicate: true) |
| 11 | likee_id well-formed |
INVALID_LIKEE_ID |
| 12 | likee_uid present |
LIKEE_UID_MISMATCH |
| 13–14 | Boostigo identifies likee_id itself and obtains the trusted UID |
USER_NOT_FOUND / SERVICE_UNAVAILABLE |
| 15 | Submitted likee_uid == trusted UID |
LIKEE_UID_MISMATCH |
| 16 | diamond is a configured amount |
INVALID_DIAMOND_AMOUNT |
| 17–19 | Configured price looked up; submitted amount == configured |
AMOUNT_MISMATCH |
| 20 | API key balance ≥ amount | INSUFFICIENT_BALANCE |
| 21–25 | Atomic transaction: lock key wallet, re-check duplicate, debit key, create order, write ledger, commit | — |
| 26 | Order queued for the recharge worker | — |
| 27 | 201 response with order_id and status: processing |
— |
Then, asynchronously:
processing→successorfailed (auto-refund)→webhook
- The worker routes the order to Boostigo's recharge providers (never visible to you), polls the result and updates the order.
success→ webhookorder.success.failed→ the amount is credited back to your API key exactly once, webhookorder.failed.delayed→ temporary delay (e.g. provider maintenance); the order keeps processing and you receive the final event later.
#Recommended client logic
- Identify → show nickname → user confirms.
- Create
request_id(your order number) and persist it before calling recharge. - Call recharge. On network timeout, retry with the same
request_id— you can never double-charge. - Store
order_id. Treat the order as pending until a webhook (orGET /orders/{order_id}) sayssuccess/failed. - Verify webhook signatures and answer
200quickly; do heavy work asynchronously.