Kalshi计划移除批量订单端点引发开发者讨论

question: those of you that use batch place/batch cancel - why? why not just use the regular place/cancel?

question: those of you that use batch place/batch cancel - why? why not just use the regular place/cancel?

When I first started with the API, it seemed promising to minimize latency and there was the decreased cost against the rate limit. I have since discovered it is not that simple, so wouldn't care if batch was deprecated.

When I first started with the API, it seemed promising to minimize latency and there was the decreased cost against the rate limit. I have since discovered it is not that simple, so wouldn't care if batch was deprecated.

sometimes i cancel multiple sometimes i cancel one. i can hit the same endpoint for both use cases

sometimes i cancel multiple sometimes i cancel one. i can hit the same endpoint for both use cases

sometimes i have a preferred order i'd like them executed in (ascending price order taking multiple strikes on a single market, e.g.), and submitting them in one batch gives me control over that, but sending many requests in parallel could result in them arriving and being executed out of order

sometimes i have a preferred order i'd like them executed in (ascending price order taking multiple strikes on a single market, e.g.), and submitting them in one batch gives me control over that, but sending many requests in parallel could result in them arriving and being executed out of order

From the POV of my client SDK, I pass in a collection of orders and it decides how to batch them. I agree that everything should just be either one or a collection.

From the POV of my client SDK, I pass in a collection of orders and it decides how to batch them. I agree that everything should just be either one or a collection.

(that is, sometimes the collection only has one item)

(that is, sometimes the collection only has one item)

this is interesting. Seems like a valid use case if this is a guarantee of the endpoint

this is interesting. Seems like a valid use case if this is a guarantee of the endpoint

Although I guess you could just do them sequentially as well

Although I guess you could just do them sequentially as well

probably with worse latency though

probably with worse latency though

hmm interesting. ok ill need to think about this a little bit more

hmm interesting. ok ill need to think about this a little bit more

looking over my order management code, this is only important to me for placement, if batch cancel went away it would be a simple change

looking over my order management code, this is only important to me for placement, if batch cancel went away it would be a simple change

It's more important for me for cancellation. Especially on shutdown easiest to batch the orders.. I could work around it though no big deal. Biggest pain point and main reason i'd like to switch to fix, is a cancel-on-disconnect. If i have 1000 orders out and have a hiccup in the system its bad. I've already had multiple 5+ figure losses due to machine issues where i've disconnected and left orders out to get destroyed.

It's more important for me for cancellation. Especially on shutdown easiest to batch the orders.. I could work around it though no big deal. Biggest pain point and main reason i'd like to switch to fix, is a cancel-on-disconnect. If i have 1000 orders out and have a hiccup in the system its bad. I've already had multiple 5+ figure losses due to machine issues where i've disconnected and left orders out to get destroyed.

Batching = Far fewer HTTP round trips (reduces risk of timeouts and other connection issues)

Batching = Far fewer HTTP round trips (reduces risk of timeouts and other connection issues)

I think >50% chance we remove batch endpoints in the coming weeks - just a heads up. (given that it's actually worse latency-wise than the regular endpoints, and it isn't cheaper rate limit wise either)

I think >50% chance we remove batch endpoints in the coming weeks - just a heads up. (given that it's actually worse latency-wise than the regular endpoints, and it isn't cheaper rate limit wise either)

granted i don't know exactly how batched orders are unpacked on the server side, but i am a little confused how it could possibly be more efficient to send individual HTTP calls on the client side. it would seem to necessarily add latency to the process

granted i don't know exactly how batched orders are unpacked on the server side, but i am a little confused how it could possibly be more efficient to send individual HTTP calls on the client side. it would seem to necessarily add latency to the process

It is probably slightly less efficient for us on the api gateway service itself, but we don't really care about api gateway efficiency because that's trivially easy to scale

It is probably slightly less efficient for us on the api gateway service itself, but we don't really care about api gateway efficiency because that's trivially easy to scale

but if i have 20 orders it would have to take longer for me to submit each of them with their own http call than to batch them and send them with one

but if i have 20 orders it would have to take longer for me to submit each of them with their own http call than to batch them and send them with one

well if you're waiting for each one to come back to you yeah

well if you're waiting for each one to come back to you yeah

guess that's how i was thinking of it

guess that's how i was thinking of it

guess i'll fire them off in parallel, pray they arrive in the order i want, and deal with the mess 1 rtt later if they're rearranged in a way that impacts execution

guess i'll fire them off in parallel, pray they arrive in the order i want, and deal with the mess 1 rtt later if they're rearranged in a way that impacts execution