Whole-market snapshot feeds
- Thread starter _wd
- Start date
Hopefully will sign up real soon, thanks
Polygon.io
Sponsor
One last question for you, and I'm sure you get a lot.. how come no OPRA? I get the impression from elsewhere there may be something special about their licensing. Alternatively perhaps it is just the sheer volume of data involved?
Thanks again
Polygon.io
Sponsor
OOOOOOOOOOMGGGGGG. I think I just peed myself
Do you sell I <3 POLYGON t-shirts? I want to wear one while buying that beer..
So after cleaning up the pee, I signed up for your trial, and I must say at present I simply wouldn't be happy spending $200/mo. on what I've found.
Your documentation is /sorely/ lacking:
- Fields are only described as far as 3 words, and if I cannot find some equivalent field in the CTS/UTP spec, such as in the case of the string 'Trade ID' field, I really don't even know what I'm paying for. What is a Trade ID?
- Field types completely, and dangerously, incorrect. Price documented as an integer (much like it would be sent in CTS) but in the JSON it is a float. Why the change? Floats have precision issues
- Fields marked mandatory that apparently are optional, such as 'y'/'f', while fields marked optional ('t') that are apparently always present
I can muddle ahead and assume this is just a minor docs issue, or I can play cautious and assume if the docs for the very first endpoint I tried have these errors, what am I going to find when I begin to investigate the data? Will those investigations occur before or after a trading error?
There is also insufficient information on the behaviour of the web socket. For example, looking at all AAPL trades, there were 685,420 on Friday. Each JSON object comes out around 110 bytes encoded, or around 75 MB data just for the AAPL symbol. This number obviously multiplies fast for whole-market view.
It's not hard to see there may be capacity issues during peak hours when observing the whole market. The FAQ lists average messaging rates, but these aren't useful to design for worst-case behaviour. Do I need a machine with a gigabit connection to handle peak? Will the feed inexplicably get laggy in the middle of the trading day? I assume so because the information required to ensure this wouldn't happen is missing from the docs.
Your documentation is /sorely/ lacking:
- Fields are only described as far as 3 words, and if I cannot find some equivalent field in the CTS/UTP spec, such as in the case of the string 'Trade ID' field, I really don't even know what I'm paying for. What is a Trade ID?
- Field types completely, and dangerously, incorrect. Price documented as an integer (much like it would be sent in CTS) but in the JSON it is a float. Why the change? Floats have precision issues
- Fields marked mandatory that apparently are optional, such as 'y'/'f', while fields marked optional ('t') that are apparently always present
I can muddle ahead and assume this is just a minor docs issue, or I can play cautious and assume if the docs for the very first endpoint I tried have these errors, what am I going to find when I begin to investigate the data? Will those investigations occur before or after a trading error?
There is also insufficient information on the behaviour of the web socket. For example, looking at all AAPL trades, there were 685,420 on Friday. Each JSON object comes out around 110 bytes encoded, or around 75 MB data just for the AAPL symbol. This number obviously multiplies fast for whole-market view.
It's not hard to see there may be capacity issues during peak hours when observing the whole market. The FAQ lists average messaging rates, but these aren't useful to design for worst-case behaviour. Do I need a machine with a gigabit connection to handle peak? Will the feed inexplicably get laggy in the middle of the trading day? I assume so because the information required to ensure this wouldn't happen is missing from the docs.
Nanex? He said the quote is out of his price range. He is trying to subscribe to ALL equities trades+quotes. For scanner, not market making or even trading. Floating point up to SIX decimal points should be the least of his concerns!