The timeout rule
timeout lands about 30 minutes after createdAt. Miss it with no deposit and the order moves to TIMED_OUT for good. A detected deposit removes expiry entirely, even when confirmations run past the stamp. Never fund an expired order: check the status right before sending, and create a fresh order if the window closed.
The bounds bind your deposit
Creation never validatesintendedAmount against the pair’s limits. An intent below the minimum still returns 201, with initialQuote: 0 as the tell. So does intendedAmount: 0, which the quote endpoint would reject with Invalid amount: 0; check for zero yourself before creating. What’s enforced is the deposit you actually send, which must fall between the order’s minimalAmount and maximalAmount, both in deposit-token units. Those bounds are set per order at creation and can differ from GET /v1/tokens/swap-limits for the same pair; minimalAmount has come back higher than depositTokenMin. Treat swap-limits as a pre-check and read the binding numbers off the 201 response before any funds move.
Terminal states
COMPLETED, ERROR, and TIMED_OUT never change again, so stop polling and close any open stream. After TIMED_OUT, create a new order whenever you’re ready. After ERROR, send the UUID to support.
Read the state any time with GET /v1/orders/{uuid}; the UUID is the only credential, so don’t leak it. Track orders shows the polling and SSE patterns.