As I poke around the SOTA API, I have found a few discrepancies between various APIs and also the Summit List CSV file that’s provided elsewhere:
First of all, the BonusPoints field that is found in the CSV file does not appear to be provided anywhere in the JSON APIs documented through Swagger or in the actual data downloaded from them. This is not a big deal since I am already downloading and parsing the CSV data, but it means that I can’t completely replace it with the JSON data.
Second, while the Swagger docs show that the same data-type, SummitViewModel, is used for summit data listed on both the GET region and GET summit JSON APIs, several of the fields provided through the region API for summits are nulled out including regionCode, regionName, etc. They are present, but have the value null. This is somewhat understandable as they are duplicate information as what can be found in the region section at the top, but the documentation does not make this obvious. I’ll need to rework my app a little to account for this.
The third big discrepancy is a little more interesting. There are fields present in the GET summit API that have the value null, but have the proper value in the GET region API and the CSV file data. In particular, activationCount, activationDate, and activationCallsign are null in the summit-specific API call, but have valid data elsewhere. This is data that is more likely to change regularly so I’m not sure why it’s not filled in on the summit-specific GET JSON call. On top of that, the field locator is null in the GET region and non-null in the GET summit API. Ultimately, I’d need to combine information from the CSV file, GET region API, and the GET summit API and then merge it where non-null data takes priority in order to get the full picture of a summit. I do realize that I can easily calculate the locator value myself, but it would still be good to fix.
There may be other discrepancies as well, but this was what I’ve seen so far. Any ideas from the devs on this?