filingHistoryList resource start_index value type

I am using GET https://api.company-information.service.gov.uk/company/{company_number}/filing-history

The documentation of what is returned specifies "start_index": "integer", and that is what I would expect. However, the actual JSON returned does not have a number for start_index, but a string (representing a number). That appears to me to be a bug. It is inconsistent with "items_per_page": "integer" and "total_count": "integer".

I just tried this and it seemed to be working as normal (I’ve clipped out the items):

curl -uMY_API_KEY: “https://api.company-information.service.gov.uk/company/04253605/filing-history

{
    "start_index": 0,
    "items": [
    ...
    ],

    "total_count": 82,
    "filing_history_status": "filing-history-available",
    "items_per_page": 25
}

Did you pass in an items_per_page / start_index - have you an example?

@voracityemail, thank you for looking at this. I am passing in items_per_page and start_index. Using your example, if I run:

curl -uMY_OWN_API_KEY: "https://api.company-information.service.gov.uk/company/04253605/filing-history?start_index=0"

it yields (edited):

{"filing_history_status":"filing-history-available", ... "items":[ ... ],"start_index":0}

which is what I would expect (the type of start_index is number). However, if run:

curl -uMY_OWN_API_KEY: "https://api.company-information.service.gov.uk/company/04253605/filing-history?start_index=1"

it yields (edited):

{"items_per_page":25,"total_count":82,"items":[ ... ],"filing_history_status":"filing-history-available","start_index":"1"}

which is not what I would expect. The type of start_index has changed to string.

I am trying to write Haskell bindings to the API. Haskell is a statically typed language and it complicates matters if the returned types are not consistent.

Ah - the missing info was that you were passing in values.

Good spot. Playing around with this shows that anything above 0 seems to be returned as a string. Looks like a 0 / non-zero bug. (Either our own code is doing smarter data cleaning than I recall or two wrongs make a right and we’ve been lucky… From bitter experience we do intrinsically distrust this dataset to always be as it is specified. Companies House repeatedly remind everyone that they do little if any validation / checking of input).

Seems to be limited to filing history - I tried the other paged endpoints and they looked OK. Examples:

Search:
https://api.company-information.service.gov.uk/search?q=tesco&start_index=10&items_per_page=10

Appointments
https://api.company-information.service.gov.uk/officers/9iPTdA6OFPXYQnSPuw1mOO2i0A0/appointments?items_per_page=4&start_index=4

Officers
https://api.company-information.service.gov.uk/company/04253605/officers?start_index=4&items_per_page=4

PSCs
https://ap.company-information.service.gov.uk/company/OC305357/persons-with-significant-control?items_per_page=4&start_index=4

If you’re really keen I suppose you could even have a look at their Github - assuming the API code is public - and suggest a fix!

Thank you. I had a look the various GitHub repositories. If the API code is public, I could not find it there.