Skip to main content

Create a new order + attempt AUTOMATIC payment from balance

POST 

/orders

Flow with 3 outcomes:

  1. If StockService::isAvailable(pid) = false → 409 product_unavailable. 1b. If a sub-option CLOSED for reseller sale (e.g. an out-of-stock location) is selected in extra.configoptions → 409 config_option_out_of_stock (Rabisu Master mod_rabisu_master_configoption_stock.in_stock=0). The reseller module already hides these; this is the server-side second line of defense.
  2. If period is outside the whitelist → 422 invalid_period.
  3. WHMCS AddOrder -> an order + unpaid invoice are created.
  4. The reseller's auto_apply_credit toggle (GET /auth/me) is checked:
    • false -> ApplyCredit is SKIPPED; status=pending_payment, payment_applied=false, notice=auto_apply_credit_disabled. The reseller pays the invoice manually (from the panel / by bank transfer) as it prefers. The toggle is enabled via the admin CLI: php bin/api-key-update.php <id> --auto-apply-credit=1.
    • true (default) -> WHMCS ApplyCredit (SINGLE call), depending on the result:
      • success -> status=pending_provision, payment_applied=true; the WHMCS InvoicePaid hook triggers the virtualizor queue cron.
      • insufficient funds -> status=pending_payment, notice=insufficient_credit; the reseller can pay manually.
      • HTTP 5xx / timeout -> status=payment_failed, a record is opened in RequestLogger with an alarm flag.

Actions NOT called: AcceptOrder (the WHMCS InvoicePaid hook already kicks in), VirtualizorClient (the WHMCS cron installs the VPS), balance pre-check, DeleteOrder (even in the insufficient edge case).

The Idempotency-Key header is REQUIRED (otherwise 400 missing_idempotency_key). For a same key+body replay a 202 cached response is returned.

Request

Responses

The order has been written to the DB. status reflects the ApplyCredit result; poll GET /orders/{id} for the VPS to be installed.

Response Headers
    X-Idempotent-Replay

    Becomes "true" on a repeated request served from cache.