Coverage of companies in API v URI v WebCheck

API Issues
#1

I’ve found that, for dissolved companies, some of them are in the API system, and some are not. Of the missing ones, some are in the URI system, for example here is a URI for a company which is not in the API:
http://data.companieshouse.gov.uk/doc/company/01366886.html
Please can you port all the URI data into the API, so we don’t have to guess which interface to use to find the data? A one-stop interface would be great.
Also, I use the older Companies House WebCheck resource to search for companies manually, and I find that the list of former names of a company is often more extensive in WebCheck than in the API or URI. Again, please can you port all of the data on previous names into the URI and API so that they are consistent?

#2

The API only contains approximately 6 years of dissolved companies.
The company 01366886, was dissolved in 1997, so is not on Beta/API.
The number of former names on beta/API and WebCHeck should be the same eg 00001419 has 8 on both.
If you have any specific cases of inconsistent former names, please let me know so we can investigate.
Thanks

JSON class object for Company Search within c# windows app
#3

Thanks, I will send an example next time I see it. Also please answer my middle question above:

One of my programs first tries the API, and if it finds nothing there, then it goes to the JSON version of the URI. However, they are in different formats (field-names, enumeration) so I have to code for both. It also means I cannot easily link from my site to the correct UKCH site (either API or URI, depending on the company).

#4

Also, it is arbitrary to store only 8 former names. This was probably a poor design choice, by using 8 columns in one table for the entity (as appears in the monthly dump) rather than a separate table of name changes. In my database, I keep a separate table of name changes.

There are only 3 columns: the company ID, the name, and the “until” date for that name. A company can only have 1 name at any time, and must have 1 name at any time, so I only record the “until” date for each former name. The “from date” is of course either the incorporation date, or the date of the previous name change, so you don’t need to store that or return it in the API.

One theoretical exception would be if a company changes its name more than once in the same day - in which case either use a DATETIME field (so we know which came last), or just give us the name at the end of each day and skip any “quantum name” that only briefly popped in and out of existsence.

#5

I’m sorry, but I am struggling to understand this last post. Is it a question or a statement?
We do not store ONLY 8 former names, we store all of the former names. Where have you got this 8 from?
Try 00201671 for instance, that has 10 former names.
You mention one of our bulk products, but that has its own specification and this forum is not the place to discuss that, but I can put you in touch with someone if you do want more information.
As a customer, you do not need to use all of the data we provide of course, but please remember that you are not our only customer.

#6

Apologies, I meant 10, and yes I was referring to the files on the “Free Data Product” download page, where the former names are stored in 10 columns of the table (with 10 dates).

So in the API, would I be correct in stating that an unlimited number of former names is returned? How far back does the name history in the API go, bearing in mind that some companies have existed over 150 years?

Separately, my question about the dates for previous names returned by the API is this: Why is it necessary to return the “effective_from” date, when it should be the same as the “ceased_on” date for the previous name? I assume the company cannot have no name. So it would save bandwidth if you did not send the “effective_from” date.

#7

yes, as many as we have stored eg 01246083

Your question
Why is it necessary to return the “effective_from” date, when it should be the same as the “ceased_on” date for the previous name?
Answer:-
Other customers want it

#8

Hi MArk, I don’t think that’s a good reason to be sending redundant data! Customers who want the “effective_from” date can get it from the previous “ceased_on” date. By comparison, the older URI sends a JSON object with each change of name date (therein called the “CONdate”) once rather than twice:

http://data.companieshouse.gov.uk/doc/company/01246083.json

So I suggest this simplification be considered for the next update to the API. Anything which reduces the data load without compromising the content should be a good thing, no?