It's time for another update on our progress of the v3 API and we've got our first major output format changes and a new dated release version.
Within the dropdown selector for the v3 API in your dashboard you'll see a new dated version called 10th of October 2025. In this release we altered how absent data is displayed, previously in the 12th of August 2025 release we placed a string called "Unknown" in the values of keys which lacked data.
We know that this was not optimal and after receiving feedback from customers we changed this to show null instead which is the more acceptable way to show absent values for keys especially when using the JSON API format that our API utilises.
The second change we've made is the last_updated key in the result format near the bottom used a Unix epoch, we have now changed this to an ISO 8601 UTC format which is still precise to the second like before but is also human readable.
Since both of these changes are breaking data formatting we issued a new release so those who have been testing the new v3 API in production can transition at their own pace.
One other thing we wanted to discuss, we recently discovered a bug in the client-side CORS example Javascript code available for both our v2 and v3 API's. The bug caused the Javascript code placed on your website to always trigger (and thus detect your website visitor as a proxy) when the API responded with a warning status code. The bug was caused by an operator precedence issue and we've since updated the CORS code examples.
However since most users will not check to update their code we've made the decision to alter all versions of our API so that when you make a CORS request and you will have received a warning message we'll change these to show an ok message instead. This change only affects two kinds of warning messages and only for CORS requests, those are:
- You're within 10% of your query allowance for the day
- You've gone over your query allowance and a burst token has been consumed.
Just to re-iterate, this change will only occur if you're making a CORS (client-side) request. We will not change the status from warning to ok if you're making a server-side request.
We didn't make this decision lightly, we felt it was important enough to make sure customer websites didn't become inaccessible and these two warning messages are likely not being monitored by CORS implementors anyway as the messages are predomintly not logged and the API response is consumed by the browser of the visitor to your website.
So that's the updates for today, thanks for reading and have a wonderful weekend.