I maintain [SOTAcat] and have just adapted it to the latest https://api-db2.sota.org.uk/api. I noticed the return fields are all camelCase except for AltM, and AltFt, e.g.:
{
"id": 1770,
"timeStamp": "2024-11-01T01:41:33.462983Z",
"activatorCallsign": "ZL/VK3BCM",
"activatorName": "Brian",
"callsign": "VK3BCM",
"comments": null,
"frequency": 14.31,
"mode": "SSB",
"summitCode": "ZL1/AK-027",
"summitName": "Pukekohe Hill",
"AltM": 222,
"AltFt": 728,
"points": 1,
"userID": 5273,
"type": "TEST",
"epoch": "ee54ba88-722f-408d-889f-861a6f7d24cc"
}, This inconsistency is tweaking my ocd nerve.
Given that this change was just made this week, I wonder if it can be quickly fixed before other apps adapt and the inconsistency pervades?
I’ve annoyed enough people with recent changes that I am not making an update to the API until after I get back from my holidays in mid December.
Besides, I then also have to update all my other code, test it and deploy it to handle the changed schema.
I appreciate your OCD but nah, deal with it for a while yet
As the developer of a Node-RED flow for spots and alerts, I also noticed that the “type” field can be “QRT” or "TEST for the two special cases. However, for a regular spot the type field is sometimes “NORMAL” but is often just null. The way I have chosen to handle this for now is that I check for “QRT” and “TEST” and anything not matching these two strings is assumed to be a normal spot.
Interestingly, while the JSON fields for spots have significantly changed (e.g. summitCode is now the entire summit designator rather than it being split between an association field and a region field, summitDescription has been replaced with summitName, AtlM, AltF, and points), the Alerts endpoint maintains the older fields which are harder to parse. Since I already have the code for doing that, it’s not a problem, but it’s not clear why the Alerts endpoint didn’t change to the new fields as well.
I’m hoping that the admin endpoints will be supported with the new API as I use them for downloading things like summits that a user has chased already or summits that a user needs for SOTA complete.
I must add kudos to the API team (you’re a team, right Andrew) for producing a very capable API. It is vastly superior to what the POTA guys have.
In all the instructions I’ve given to people, this has been explicitly called out - if type is missing or null, it should be interpreted as NORMAL. Obviously if I’m not aware of the app (or have lost the original email that was sent), I would have shared that with you ahead of time, but I was always going to miss someone - please don’t take it personally 
If you mean the api-db/admin ones they’ve been on the new API for years, since the SOTAData3 transition. They’re almost certain to get switched off around year end, as I can see there’s hardly any usage of them now, and it’s a pain to support them. If you PM me the exact links you’re using, I can tell you the new URLs.