You allow us to pass a variable through, but then limit it to 100 items… is this intentional? can it be changed?
This is intentional and is configured this way to provide a consistent level of performance and protect the service from requests which could attempt to return the whole dataset and consume resources at the detriment of other customers. This is a global setting and we believe perfectly adequate for customers, however, we would be interested in why you would potentially like this changed?
The only reason anyone would request the latest 100 items of a company’s filing history is if they want to see all the items in a company’s filing history, so those users are just going to be making multiple calls to get the rest of the history anyway so it just feels like an unessecary obstacle because it’s going to consume the same amount of resources (more?) eventually anyway.
We know from many years of usage stats and customer insight that the most common use case is for a client to request the latest filing history transactions.
Even though making multiple requests actually uses slightly more resources than getting the whole filing history in one go, doing so enables the available resources to be spread across a wider client base. Higher numbers of smaller transactions reduces the time a client must wait for a response. We serve the same amount of data (give or take) but we’ve actually served more clients. Also, mobile applications want smaller, chunked data, so that the application UI stays “alive”.
The 100 item cap is approximately high enough for 80% of clients to find what they want with one API request for 80% of companies, even more so if you employ filtering, as the end user generally does not want everything.
If your use case is to get the whole filing history and display it, it would be a of great help to understand what you customer requirement is, and how you get that to work, given the size of a significant number of filing histories (it’s always interesting!).
As usage models change, or data sets change, we would look to review this page size. The more informed we are of client use cases, over time the better we can tune the API, and scale our infrastructure.
That raises a question. Does filtering work? Does filtering help?
Cheers!
Probably worth noting that this isn’t a particularly big issue for us. I have code in place to iterate through all the pages when we need to go beyond 100 items. It’s more of a convinience/complexity (and possibly laziness) thing because we need to be able to account for the other 20% (or less) cases when we are going to hit the limit.
FWIW I’ve been using British Airways PLC to stress test my big filing history code (https://beta.companieshouse.gov.uk/company/01777777/filing-history). 3100 items give or take! As such, this takes 31 indvidual calls and the API is lightning fast and responsive to the extent where this is a problem.
We’re not using the filters at present. I like the idea in principle, but essentially we are working with our own custom filters that aren’t an exact 1:1 match for the Companies House ones, as such we need to access the entire file history before processing it, most of the time.
There is an extent to which rate limiting and trying to keep things scalable factors into it. If usage ever reached a point where this was an issue, then obviously, from our point of view, 1 call is better than 31.