What API do you use for trade execution and why?

Kalshi

Kalshi

Sponsor
I’m curious - what APIs have you all elected to use for trade execution? Was it because of a particular feature, good docs, or did you just hear good things? If you remember how you heard about it, that would also be really helpful to hear.

We’re currently working on improving the API for our exchange and we’re trying to figure out how we can really make it great. We’ve done simple things (Python package, interactive docs, etc.), but would love to hear what’s really blown you away in your past coding experiences.
 
It is so hard to find a good API for execution. For beginners, Rest is good. for advanced, FIX; for the middle, maybe grpc is a choice. all these are language agnostic, so every program can connect with api.
 
Having coded for a couple of retail/noob platforms the past 5-6 years:
REST API for execution + streaming API seems to be the typical baseline, although the fact that typically the streaming API (for prices and sometimes account state updates) is provided on a codewise separate channel leads to slightly higher complexity in the user's code. Of course, the stream is there because REST request polling is a bad idea... Somehow the fact REST is at all chosen and then requires another stream channel to be practically useful somewhat irks me.

It should be obvious but not providing reasonably timely price data for certain tradable instruments (even for a fee if necessary) so the user doesn't know the officially quoted price is kind of a dick move. (Looking at IG here...)

Being clear in docs about known errors is important.

Poorly thought out usage restrictions can be a concern. E.g. only allowing one concurrent connection/app per account: it's very convenient for the API provider but it puts the weight on the end user to build their API access into a single app and thus single point of failure.

When marketing this, I'm not sure it matters though. Retail monkey sees the phrase "REST API" ("I'm familiar with that!") and makes the decision to try it.
 
Last edited:
Got it - thank you all so much for the feedback. I'm sure there are a lot of REST APIs/Websocket options out there, so I'm just curious what made you pick the service that you wound up going with. Was there a particular standout feature, or did you just pick it because it seemed like a popular choice?
 
Kalshi said:
Got it - thank you all so much for the feedback. I'm sure there are a lot of REST APIs/Websocket options out there, so I'm just curious what made you pick the service that you wound up going with. Was there a particular standout feature, or did you just pick it because it seemed like a popular choice?
More...

I think the one would decide on the platform for entirely different reasons than API (e.g. market access, cost structure, tax incentives), but a sufficiently powerful API being a condition to proceed.
 
You must log in or register to reply here.
Back
Top