Skip to main content
This is the integration recipe. For the full contract — every field, every error code, the email behaviour — see Maintenance notifications.

​
What you are trying to do

Know that a window is coming early enough to do whatever your side does about it — pull quotes, flatten, hand over to another venue, page someone — then sit it out and resume when the platform is back. What you do with the warning is yours. This page is about getting the signal right and at the right time. Two endpoints give you everything you need, and they answer different questions. Use both — neither replaces the other. Both take your partner API key in X-Api-Key.
Plan from the schedule. Act on the status. The two can disagree for a few minutes, and the section on when they disagree explains why that is normal rather than a bug.

​
The recipe

​
1. Poll the schedule, slowly

Once a minute is plenty — the response is cached for 5 seconds and the data changes a few times a week.
?scope=trading returns both trading windows and full-platform (all) windows, because a full freeze stops trading too. A withdrawals window does not affect order flow; leave the filter in place and you will not see one. Keep the windows you get, keyed by id. Pass the response’s generatedAt back as your next from so you never miss a transition.

​
2. Decide your lead time and trigger your own wind-down

Pick how much warning you need — ten minutes is a common ask. Then:
run your wind-down is whatever that means for you. Some desks stop placing and cancel everything, some only widen, some move flow elsewhere, some just notify a human. We do not assume which. Announced windows normally arrive 24 hours or more ahead, so this fires with plenty of warning. An incident window can arrive with no notice at all — handle that case too (see step 5).

​
3. Know what still works while it runs

While a window covering trading is running, this is what the platform does:
  • POST /api/orders/place answers 503. Do not treat that as a rejected order and do not retry it hard.
  • Cancels keep working. Single-order cancel stays available even under a full platform freeze, by design — the ability to unwind risk is never taken away from you. Whether you use it is your call, but the option is there even if a window catches you mid-flight.
  • Your existing positions are untouched. A maintenance window is a pause on order flow, not a settlement event.

​
4. Resume on status, never on the clock

This is the part that most often gets written wrong.
Do not resume at expectedEndAt. That field is a promise we make to you, not a timer:
  • We frequently finish early — the window closes the moment the release is verified back, which is often well before the time we announced. On a recent release the window closed 17 minutes early.
  • We sometimes run late. The window stays in_progress past expectedEndAt, and you will get an extended notice if we move the promise. Resuming on the old clock would put you back into a surface that is still down.
maintenance.trading.status == "operational" is the only signal that means “we are back”.

​
5. Handle the no-notice case

Not every outage is announced in advance. Your /status poll is what catches those: degraded is the same alert that pages our own on-call, so you learn when we do. There is no window id under it and no promised end, because nobody declared it.

​
When the two disagree

A window shows startsAt: 19:00, it is 19:05, and /status still says operational. Nothing is broken. A window becomes real when an operator presses Start, not when the clock reaches startsAt. The announced time is when we intend to begin; the status is what has actually happened. In practice the two are minutes apart, and either direction is possible. What that means for you:
  • Use startsAt to prepare — stop quoting, pull orders. Being flat a few minutes early costs you little.
  • Never infer the end from the start. A window that has not started cannot end.
  • A scheduled window whose slot passes without it starting disappears from the feed. It is not going to happen as announced. If you are holding it, drop it and resume.
If a window regularly starts far from its announced time and that is costing you, tell your account manager — we would rather tighten our side than have you widen your lead time.

​
Worth knowing

One partner, one bucket. All of your API keys share one rate limit of 600 requests per minute per endpoint. Polling both endpoints once every 30 seconds uses about 4 of them. Upsert by id. You will be shown windows you already have for up to a minute after they change — that overlap is deliberate, so a transition that was mid-commit when you polled still reaches you. Subscribe a mailbox too. The API is the machine signal; the email is how a human on your side finds out. Ask your account manager to add an address — you get scheduled, started, extended and completed notices. See Email notifications. If you cannot reach us at all, treat it as an outage you have not been told about: stop quoting and back off. A 401 means your key is missing or wrong, not that the platform is down — these endpoints have required a partner key since 2026-10-13.