> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vane.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Real-time tracking

> Poll the order endpoint, subscribe to the status stream, or run both. Always fetch the current state first.

Every order can be followed to a terminal state by polling, over SSE, or both at once.

Polling `GET /v1/orders/{uuid}` returns the full order with no credentials; the UUID alone is the read key. Every 5 seconds is plenty, since transitions wait on block confirmations anyway. The stream pushes an `orders:status-update` event on each change, carrying only `{orderId, status, message, updatedAt}` with the UUID as `orderId`, so treat every event as a cue to re-fetch the order.

```bash theme={null}
# 1. Read the current state; the stream won't repeat it
curl -s https://api.vane.xyz/api/v1/orders/7f9c2e4a-1b3d-4c5e-8f6a-2d9b0c1e3f5a

# 2. Subscribe (this is the one path without /v1)
curl -N https://api.vane.xyz/api/orders/7f9c2e4a-1b3d-4c5e-8f6a-2d9b0c1e3f5a/status-stream
```

The order of those two calls matters. The stream sends no initial event, so fetch first, subscribe after, and re-fetch on every reconnect. Reconnects are routine: the server closes any stream that stays silent for 60 seconds, `EventSource` reopens it automatically, and raw HTTP clients need a loop. The rest of the contract is on [Order status stream](/api-reference/order-status-stream).

Use polling alone for backends and scripts. Add the stream when a user is watching a status screen and seconds matter, with a slow poll underneath as a safety net; working loops with reconnect handling are in [Track orders](/api-reference/track-orders). Either way, stop once a fetch shows `COMPLETED`, `ERROR`, or `TIMED_OUT`; terminal orders never change again.