Motivation for creating this library / fighting with the REST API

[Bomper]

First of all, thank you very much for creating this tool, @Voyz. I've been using it since you fixed #225 and it's working great. Well, as great as it can, because it still has to restart the Client Portal gateway when it freezes, which means there will be downtime, guaranteed, of a few minutes at a time, several times a day in practice.

I was interested in IBeam because I was hoping the IB REST API would be easier to use than the stream-oriented TWS API, which was so weird that I had to use wrappers right away: the FIELDS OF an object, say an account summary, were STREAMED (WTF?). But anyway, with various wrappers, the TWS API worked and it was stable, requiring only one 2FA login per week, during the weekend. I can deal with that, and pretty much all ATSs can.

But as I actually looked into the REST API, what others said was confirmed to be true: it was a nightmare. Not just because of the restart requirements, but look at how confusing and inconsistent the endpoints are. Just to get contract details, you have at least three endpoints:

• Contract information by Contract ID
• Search SecDef information by conid
• Search the security definition by Contract ID

Though some contract details are also returned by the Security Future by Symbol endpoint (conId, expiration dates) and the Live Market Data Snapshot endpoint among the Market Data Fields: SecType, Company name, Industry etc. - these are not market data like the bid/ask/volume, greeks, indicators and so on. And by the way, these market data field IDs are incompatible with the TWS API tick types.

So 5 (five) endpoints to get contract details. And not one of them gets ALL the details (exercise for the reader: get the multiplier of a contract). And they break compatibility with the established TWS API.

This is crazy.

Keep in mind that IB has been working on this REST API since 2018. And it's still the most disorganized API I've ever seen. Look at how many names there are for the underlying conid field: undConid, underlyingConid, underlying_con_id, underlying_conid. They can't even decide on one name for the option right field, it's right or putOrCall. Or the most basic of all fields, symbol, is sometimes returned as ticker .

Who wrote this crap?

So it seems to me that with a wrapper, the stream-oriented old TWS API is the lesser evil, as another dev said. A good wrapper can abstract the streaming nature when it doesn't make sense. And the field names are consistent.

But with the REST API, there's just no way to avoid the sudden disconnection problem, which can be a show stopper for many unattended trading scenarios.

So I'm honestly curious,

• what was the motivation for writing IBeam
• what is the hope for still working on it?
• when is IBeam still useful given that connecting directly to api.ibkr.com via OAuth is apparently possible for regular users? (I haven't yet fully audited or tried that client)

[Voyz]

Hey @Bomper thanks for sharing your thoughts. Let me address your questions:

Who wrote this crap?

As much as I sympathise with your frustration, I'd suggest to refrain from this kind of language. IBKR aren't all bad, there surely are developers there who try to provide some reasonable service to us, but likely are restrained by management or resources. We know next to nothing about the types of scenarios, clients and legacy compatibility they need to support, which may well explain the reasons behind such a convoluted system.

what was the motivation for writing IBeam

To automate the authentication with their new REST API. At the time it was originally written, around 2019, it wasn't as obvious as it is today that the REST API has so many issues. And they do improve it over time.

what is the hope for still working on it?

I don't understand this question - can you elaborate? Do you mean: why am I still working on it? Because it works, despite its issues, for many users including myself. I've spoken to people who've been using it for years, and as you know the alternative TWS API is not without flaws itself.

when is IBeam still useful given that connecting directly to api.ibkr.com via OAuth is apparently possible for regular users?

To be honest this sounds like a subjective question. If IBeam and CP Web API with the Gateway are not useful to someone, then that's fine. Currently OAuth is not fully supported and the Gateway has not yet been disabled. Until that happens and there are people using it, IBeam will remain useful.