Order Lifecycle

The flow from creating a VPS order to the service becoming active is asynchronous: the order is created instantly, while the actual VPS provisioning completes in the background.

1. Create an Order — POST /orders

Idempotency-Key is required (duplicate-order protection).

curl -X POST https://api.rabisu.com/api/v1/orders \
  -u "rsk_live_xxx:rsks_yyy" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 9f1c2d3e-4b5a-6c7d-8e9f-0a1b2c3d4e5f" \
  -d '{
        "product_id": 101,
        "period": "monthly",
        "config_options": { "12": 3, "15": 1 },
        "extra": { "domain": "vps01.customer.com" }
      }'

The response (202 Accepted) returns a provision record. The id field is your reseller-side correlation key (store it in your local record):

{
  "success": true,
  "data": {
    "id": 5001,
    "status": "pending_provision",
    "order_id": 88123,
    "service_id": null,
    "payment_applied": true
  },
  "meta": { "trace_id": "...", "timestamp": "..." }
}

2. Applying Credit (auto_apply_credit)

An invoice is generated when the order is created. Depending on your auto_apply_credit flag:

• On (default): The invoice is automatically paid from your reseller credit. If you have enough credit, provisioning is queued (pending_provision).
• Off: No credit is applied; the order stays pending_payment. You settle it manually later (see step 4). This gives you a pre-provisioning review window (fraud/hostname checks, etc.).

If credit is insufficient, an insufficient_credit notice is returned and the order waits in pending_payment.

3. Provisioning Status — GET /orders/{id}

Once the VPS is provisioned, a service_id is assigned and the status becomes active. Poll the status:

curl -u "rsk_live_xxx:rsks_yyy" \
  https://api.rabisu.com/api/v1/orders/5001

Provisioning states:

Status	Meaning
pending_payment	Awaiting payment (credit not applied)
pending_provision	Paid, VPS provisioning queued
active	VPS provisioned, service_id assigned
failed	Provisioning failed

Tip: Instead of continuous polling, use Webhooks — the service.created event is delivered instantly when the VPS is ready.

4. Settling a Pending Payment — POST /orders/{id}/settle

If the order is pending_payment (credit was insufficient or auto-apply was off), trigger payment after topping up your balance:

curl -X POST https://api.rabisu.com/api/v1/orders/5001/settle \
  -u "rsk_live_xxx:rsks_yyy"

This endpoint is naturally idempotent: an already-paid order returns a no-op with already_applied. After a successful settle, provisioning is queued.

5. Managing the Service

Once the service is active, you can use the service endpoints:

• GET /services/{id} — summary (IP, hostname, status)
• GET /services/{id}/status — live CPU/RAM/disk
• POST /services/{id}/power/{action} — start/stop/restart/poweroff
• POST /services/{id}/rebuild — OS reinstall
• POST /services/{id}/upgrade — resource upgrade (prorated difference invoice)
• POST /services/{id}/suspend · /unsuspend — suspend / unsuspend
• DELETE /services/{id} — terminate (disk wiped, Idempotency-Key required)

See the OpenAPI reference for all field details.