Extraordinarily unlikely. I mean, the data fed to the API isn't really by a queue to my knowledge, and they are used to communicate between some microservices, not all.

Plus, doing so would bypass all authentication, rate limits, logging, user control etc. Would it be possible to add an authentication mechanism of some kind to achieve this? Yes. Would it be worthwhile? No.

There's a reason APIs are the standard and not shared messages queues for loosely coupled and detached services.

And I may have asked for this many times, over many years, and been given a straight no.

Had they invested in real-time tech years ago, they'd probably have saved money by now given how much effort they put into scaling the game.

With the addition of web sockets in the new item market, it does seem like they're finally changing course on the "polling-everywhere" approach. If that implementation goes well, who knows, they might increasingly see value in adding real-time streams elsewhere and, just maybe, eventually the API.

Currently, yeah, probably a hard no.

In some of my first discussions with Ched, he mentioned he'd really like to implement something like API websockets to which players could connect. Both so they can get real-time data & to drastically reduce the amount of requests. 

It's just that the current focus is to build & standardize API v2 and refactor some of the codebase, but I'm sure this is a topic we'll revisit when I get to the point of request optimization.

Of course, any ideas & suggestions regarding that topic are more than welcome, so I appreciate bringing this topic up!