Order status · Nexus Gateway

Receive progress through signed webhooks. Use GET with the same connection and external order ID to reconcile current Retail state after downtime or missing updates. Keep customer progress separate from submission and payment state.

Read progress

curl --fail-with-body "https://website.api.pionier.ro/v1/connections/$NEXUS_CONNECTION_ID/orders/shop-1001" \
  -H "Authorization: Bearer $NEXUS_WEBSITE_KEY"

{
  "external_order_id": "shop-1001",
  "status": "accepted",
  "total": 3700,
  "currency": "RON"
}

Map the status to customer language

Status	Suggested customer message	Terminal?
`pending_acceptance`	Received. Waiting for the restaurant to confirm.	No
`accepted`	The restaurant has accepted your order.	No
`preparing`	Your order is being prepared.	No
`ready`	Your order is ready for pickup or dispatch.	No
`out_for_delivery`	Your order is on its way.	No
`completed`	Your order is complete.	Yes
`rejected`	The restaurant could not accept your order.	Yes
`cancelled`	Your order was cancelled.	Yes

Progress depends on the restaurant’s workflow. Neither webhook observation nor polling guarantees every intermediate state. Pickup does not require an out-for-delivery stage. Do not require every status to appear in sequence. Optional scheduling, estimates, reasons, delivery progress and refund summaries are described below; none verifies payment or provides live courier location.

Polling fallback

With a healthy webhook receiver, you do not need continuous polling. If webhooks are not configured or temporarily unavailable, a starting fallback policy is one backend poll every 5–10 seconds while a customer actively views a non-terminal order, less often when idle. Coordinate traffic limits with Nexus; this is not a service interval guarantee. Return to webhook updates after recovery and use GET to reconcile any gaps.

Share one polling stream per connection/order across customer sessions.
Read the latest status and store the last successful result.
Stop on completed, rejected or cancelled.
On transient failures, back off with jitter and honor Retry-After. Show “temporarily unable to refresh” instead of inventing a rejection.

When status is unavailable

404 order_not_found means the gateway has no reservation for that ID under this connection. Check the ID and connection. For an unresolved submission, resend the same saved ID/body instead of creating a replacement purchase.

A gateway reservation whose downstream status cannot yet be confirmed can return 503. A status read does not dispatch an order or repair an unconfirmed submission; replay the original POST to do that.

Keep an uncertain order visible to your operations team when retries exhaust your chosen window. The gateway does not retry uncertain order submissions for you or guarantee their automatic expiry. Webhook delivery has its own background retry worker; it does not repair an unconfirmed submission.

Estimates and reported outcomes

scheduled_for preserves the requested slot; estimated_ready_at is set on acceptance. reason provides an available rejection/cancellation reason. Optional delivery includes assignment/progress and pickup/delivery estimates without courier contact details. Optional refund summarizes website-reported refunds; it does not verify payment or reverse a receipt. These fields may be null. Use the schema reference for their complete contracts.