Boostsy API order status polling workflow
Store the order ID returned by add, then use status to observe that same order. Schedule bounded requests on your server and stop routine polling after a terminal status. A status request never needs a new order or idempotency key.
Single-order JSON body
{ "action": "status", "order": "YOUR_STORED_ORDER_ID" }
POST to https://boostsy.net/api/v2 with Content-Type: application/json and Authorization: Bearer YOUR_API_KEY. Replace the placeholder with the exact stored string.
Batch JSON body
{ "action": "status", "orders": "YOUR_FIRST_ORDER_ID,YOUR_SECOND_ORDER_ID" }
The orders form returns an object keyed by order ID. Send at most 100 IDs in one status request; inspect each result separately.
Illustrative single-order response
{ "charge": "0.25", "start_count": "0", "status": "Pending", "remains": "100", "currency": "USD" }
This is a fictional response illustrating the shape, not a live order, current price or delivery forecast. Preserve money strings rather than using them as a new order quote.
The polling sequence
Read the stored reference
Use the original order ID and account-owned server credential.
Request status
Send one order or an eligible batch to the status action.
Persist the observation
Record status, remaining quantity, check time and any per-ID error.
Decide the next check
Continue a bounded schedule for nonterminal orders; stop routine checks at a terminal result.
Handle the result
| Result | Meaning for this workflow | Next action |
|---|---|---|
| Queued, Pending or In progress | The order is not terminal | Keep the same order ID and schedule a later status check |
| Cancellation requested | A cancellation request is awaiting its outcome | Observe status; do not assume a refund is complete |
| Completed, Partial, Canceled or Failed | A terminal order status | Stop routine polling and reconcile the order record |
| Incorrect order ID | The ID is unknown or belongs to another account | Check the stored reference and credential account; do not create a replacement order automatically |
| HTTP 429 | The account API request limit was exceeded | Back off and reduce aggregate request load |
Bound the scheduler
The handler allows 120 API requests per account per 60-second window, shared across API actions. A batch still needs enough room for other work. Choose an interval and maximum observation period for your application; these are integration decisions, not a promised delivery time.
Use retry backoff for a transient read failure and keep the last confirmed observation visible. A request timeout does not establish that the order failed. Do not put the API key in a URL, browser bundle or shared log.
After a partial or canceled result, use the actual order and wallet records for reconciliation. Remaining quantity and a status snapshot do not by themselves establish the amount of a completed refund.