filingHistoryList resource problems

I am using GET{company_number}/filing-history with company no. 03794021 (as a test example).

If I specify category accounts as a query parameter, the (filtered) response omits transaction id MzI3ODczMzA0MmFkaXF6a2N4 (the most recent accounts) (which does have category accounts). However, the rest of the response goes back as far as Mzg4NzQ0MDdhZGlxemtjeA (the 2000-06-30 accounts). On the face of it, the omission of the most recent accounts appears to be a bug.

If I omit the category query parameter, the (unfiltered) response includes transaction id MzI3ODczMzA0MmFkaXF6a2N4 (mentioned above) but only goes back as far as MTczOTY5NDQxYWRpcXprY3g (the 2006-06-30 accounts). I don’t know why the unfiltered response is truncated when the filtered response is not. I now understand that the items_per_page value is capped at 100 and that the start_index value needs to be a multiple of the items_per_page (where 0 specifies the first page).

My objective is to be able to query the filing history and identify a complete list of the accounts in that history.

I have answered my own question: I think the missing MzI3ODczMzA0MmFkaXF6a2N4 was an artefact of using start_index with a value of 1. I now understand that start_index is zero-based and must be a multiple of the items_per_page value.

Good you figured this out and thanks for recording that - it’s helpful for others who come here with similar problems.

Paging through the results is something that causes frequent confusion. The process is documented - if partly on this forum - but there are a couple of quirks. It could usefully be given its own documentation entry on the main documentation site.