Is there a place where maintenance times and updates are published?
Is there a place where maintenance times and updates are published?
2026-06-02 · Kalshi · 92 条相关讨论
Is there a place where maintenance times and updates are published?
Is there a place where maintenance times and updates are published?
Get Exchange Schedule (https://docs.kalshi.com/api-reference/exchange/get-exchange-schedule) has a `maintenance_windows` property. They have never used this, as far as I know. I don't think they have a process for populating this, so it is another red herring. They most recently posted to <#946568456759812096> (e.g., https://discord.com/channels/871819895443189862/946568456759812096/1507191484137603193) and have used that before. The standard maintenance window is 0300-0500 ET Thursday. This is currently published by the API. (https://external-api.kalshi.com/trade-api/v2/exchange/schedule)
Get Exchange Schedule (https://docs.kalshi.com/api-reference/exchange/get-exchange-schedule) has a `maintenance_windows` property. They have never used this, as far as I know. I don't think they have a process for populating this, so it is another red herring. They most recently posted to <#946568456759812096> (e.g., https://discord.com/channels/871819895443189862/946568456759812096/1507191484137603193) and have used that before. The standard maintenance window is 0300-0500 ET Thursday. This is currently published by the API. (https://external-api.kalshi.com/trade-api/v2/exchange/schedule)
Great, thanks!
Great, thanks!
hi all, will be bumping v1 costs again shortly.
hi all, will be bumping v1 costs again shortly.
updadting the getting started page as well, didn't realize that was still using the old endpoints
updadting the getting started page as well, didn't realize that was still using the old endpoints
This whole thing is making me think the ideal migration strategy for you all should be making the depreciated feed worse and worse to make people switch. Keep dropping from 20 QPS, to 5, to 2... eventually to 1 QPM, and every time someone comes in to complain about throttling, send them to v2
This whole thing is making me think the ideal migration strategy for you all should be making the depreciated feed worse and worse to make people switch. Keep dropping from 20 QPS, to 5, to 2... eventually to 1 QPM, and every time someone comes in to complain about throttling, send them to v2
🙂 (just to be clear, how we're doing it now? or would you change it in some way?)
🙂 (just to be clear, how we're doing it now? or would you change it in some way?)
Is this your plan? I like it if so
Is this your plan? I like it if so
yep! although we're going to get increasingly aggressive so when its sufficiently expensive we'll prob just cut it off
yep! although we're going to get increasingly aggressive so when its sufficiently expensive we'll prob just cut it off
to avoid needing to mantain it for people doing very very few requests
to avoid needing to mantain it for people doing very very few requests
For v2 order responses, the docs for `remaining_count` say > Number of contracts remaining after placement. For IOC orders, this reflects the final state after unfilled contracts are canceled. I'm having a hard time with the IOC caveat there. If I make an IOC order for `50` contracts, and only `10` get filled, should I expect `remaining_count` to equal `40` or `0`, since the remainder would have been cancelled? I think in this case, `remaining_count` would equal `0`, but I wanted to double check my understanding, thanks
For v2 order responses, the docs for `remaining_count` say > Number of contracts remaining after placement. For IOC orders, this reflects the final state after unfilled contracts are canceled. I'm having a hard time with the IOC caveat there. If I make an IOC order for `50` contracts, and only `10` get filled, should I expect `remaining_count` to equal `40` or `0`, since the remainder would have been cancelled? I think in this case, `remaining_count` would equal `0`, but I wanted to double check my understanding, thanks
yeah, would be 0
yeah, would be 0
great, thank you
great, thank you
cost of the old endpoints is now 5x the cost of the new endpoints! please plan accordingly
cost of the old endpoints is now 5x the cost of the new endpoints! please plan accordingly
Is there a doc somewhere that explains the reason why v2 was created and what to watch for when migrating over? I was only able to find the docs for just the create, batch, cancel etc endpoints
Is there a doc somewhere that explains the reason why v2 was created and what to watch for when migrating over? I was only able to find the docs for just the create, batch, cancel etc endpoints
to align the API with the matching engine's single book bid/ask structure. it's a pretty painless migration, just make sure your order execution layer is sending the correct bid/ask side and price depending on what you're trying to achieve. that's in the V2 docs
to align the API with the matching engine's single book bid/ask structure. it's a pretty painless migration, just make sure your order execution layer is sending the correct bid/ask side and price depending on what you're trying to achieve. that's in the V2 docs
If an API key gets rate-limited, when does it get unblocked?
If an API key gets rate-limited, when does it get unblocked?
yeah it automatically gets unblocked as time goes on
yeah it automatically gets unblocked as time goes on
When a user goes to place a combo does each leg they select submit a new RFQ or only once they put in a dollar amount?
When a user goes to place a combo does each leg they select submit a new RFQ or only once they put in a dollar amount?
please also update the "Rate Limits" page to tell people about the different costs and about v2 !
please also update the "Rate Limits" page to tell people about the different costs and about v2 !