[Feature Request] - Add exchange and/or mic attributes to the response from the /indices endpoint
stephenrs opened this issue · 7 comments
Is your feature request related to a problem? Please describe.
This isn't directly related to the python client, but I wasn't sure where else to post it.
I’m finding that there are some inconsistencies in the Reference Data and API structure that make it difficult to work with the API in a comprehensive and ambiguity-free way.
More specifically, exchanges are not provided in the attributes in the response from the /indices endpoint, but an exchange appears to be required to resolve ambiguity in some cases. There also appears to be some inconsistency regarding when to use 'exchange' and when to use 'mic', however, since mic is unique, it seems that it should be the standard. I think 'symbol:mic' would unambiguously identify a specific and unique instrument (rather than 'symbol:exchange')
First example:
When trying to fetch time-series data for the Stock Exchange of Thailand (SET) index, the following request targets a German stock:
https://api.twelvedata.com/time_series?symbol=SET&interval=1day&apikey=[APIKEY]
In order to get the Thai SET index, the request must look like this:
https://api.twelvedata.com/time_series?symbol=SET:SET&interval=1day&apikey=[APIKEY]
However, I haven’t found a way to use the API to know that the symbol should be ‘SET:SET’, and ‘SET: XBKK’ doesn’t work (ie, mic code doesn't work). I found this out through manual experimentation.
Second example:
SDAXI is included in the response from https://api.twelvedata.com/indices?country=germany (again, without an exchange in the attributes), however, price updates from the websocket server include an ‘exchange’ attribute, for example:
{“event”:”price”,”symbol”:”SDAXI”,”currency”:”EUR”,”exchange”:”XETR”,”type”:”Index”,”timestamp”:1673538840,”price”:13002.75}
Since my system cannot determine the exchange for SDAXI from the API prior to subscribing to SDAXI (or fetching SDAXI time-series data), the exchange attribute in the websocket packet is not of any use, and it means I have to handle websocket updates for stocks differently than for indices - this is messy and error-prone, and makes avoiding ambiguity/duplicates more difficult.
Describe the solution you'd like
It seems that allowing an exchange (and/or mic) parameter in the /indices endpoint specification, and including the exchange and/or mic in the response attributes would address problems like the ones I’ve described.
Since indices are associated with exchanges, it seems reasonable to include the exchange/mic in the attributes for indices listings.
Describe alternatives you've considered
When requesting time-series data for indices, I think the type could be set to 'index', but this wouldn't address the ambiguity/duplicate symbol problem.
It might also be possible to use the symbol_search endpoint or other endpoints to find out the exchange for an index symbol, but this would be inefficient and wasteful.
You could include the country in the time_series request like:
https://api.twelvedata.com/time_series?symbol=SET&country=thailand&interval=1day&apikey=[APIKEY]
But that wouldn't work for "India" because NSEI is traded on both the NSE and BSE, so you need to know the exchange of an index to make sure you're getting the correct one.
I'm looking forward to your comments. Thanks!
Stephen
@midasSSS Thanks for the new article, but unfortunately it doesn't solve the problems.
From the article:
"If you still need an exchange, you can map an index to an ETF or a mutual fund."
As in the original post, because of the current state of the API an exchange is required in order to fetch indexes such as SET. So, this is not a specific need of any particular user or use case. Everyone "needs" the exchange in order for the API to function correctly and without ambiguity because of the way it is currently implemented. However, the documentation neither tells anyone this nor tells them how to obtain the exchange. Also, the suggestion from the article to "map an index to an ETF or a mutual fund" is a hack that wouldn't be suitable in any professional setting. What you're suggesting could result in masses of spaghetti code for a larger implementation based on the API. This is clearly a flaw in the design of the API, objectively speaking.
From the article:
"Indices are not directly tradeable and therefore are not listed on exchanges as opposed to equities. Therefore, providing an exchange parameter in the response of /indices API endpoint is impossible."
Obviously, it's not impossible because exchanges are provided in the websocket packets for indices sent by Twelvedata, as noted in the original post. Can you reconcile this contradiction?
I would very much appreciate a more serious, rational, and non-contradictory response to this issue.
Thanks!
For some additional insight, I am currently working around this gap in the API by obtaining the exchange that the API expects for indices from Twelvedata websocket responses and hard-coding them. It sure would be nice if folks didn't need to do this to know how to reliably fetch indices.
So, the fact is that you are storing indices with an association to exchanges...and the API expects exchanges when specifying indices and resolving ambiguity, but you don't want to release this information to consumers of the API. You probably have a reason for implementing things this way, so it would be helpful if you would be transparent about it.
I don't mean to be hard on you guys, and I hope you don't take it that way. I just hope you would agree that if you're going to offer indices data then it's reasonable to expect that you would also provide a consistent and reliable way to fetch it with certainty.
Are there any updated thoughts on this?
Our product team is evaluating whether it is possible to add a new field to the /indices response; it should take no longer than a week.
@stephenrs, we've added exchange and mic_code to the reply body and to request parameters. Thanks for your feedback and input!