"care_of_name", "care_of" and documentation issues

ash · August 12, 2015, 2:44pm

I was surprised to discover that the api can return a “care_of_name” field as part of the registered office in both the companyProfile and registered-office-address responses.

There is an example of it here:

GET /company/02771869/registered-office-address
GET /company/02771869

This field isn’t mentioned in the resource for either of these calls and we have no way of knowing it exists beyond accidently stumbling across it. However, the C/O address is rendering in the Beta search site so it must be a “known quantity” as it were.

The Officer resource has a “care_of” field for officer addresses. However the only way I can check this is correct and it shouldn’t actually be “care_of_name” is to randomly look at company’s officerlist and hope to find one that has this field (I haven’t yet).

In general the problem here is twofold.

Without correct and current documentation we don’t even know what information could potentially be in a response from the API.
Even if we do know what information could potentially be in a response, we don’t know the rules for that information unless we can find an example and extrapolate from how it’s rendered in the beta search results.

These combined lead to a lot of trial and error. There are still some fields that I have scraped literally thousands of API responses looking for and haven’t found.

ash · August 12, 2015, 4:49pm

I’ve managed to find Officers with a “care_of” address and the documentation is correct here.

I had to brute force it by creating a lot of API keys and randomly accessing Officer listings until I found one.

mfairhurst · August 13, 2015, 1:36pm

Thanks for raising this and this is an issue with our documentation, and care_of_name will be returned as part of the registered office address. We will look to update the documentation as soon as possible. For consistency we will be looking to change the care_of member within the officer resource to care_of_name.

With respect to point 2 of the problem could you clarify or provide a specific example?

ash · August 13, 2015, 1:48pm

For an example of point 2…

In the chargeList resource there is an boolean field “items.more_than_four_persons_entitled” it is optional and only applied to charges submitted after April 2013.

So I know this field can exist and it’s meaning is fairly obvious. What I don’t know is why it exists, whether or not it’s existance has implications for any of the other values returned and what, if anything, I have to do to take it into account in my own applications.

I can make a couple of educated guesses, but I don’t know which, if any, of them are correct. If I could find an example of a company that has this field then I might be able to figure it our from looking at the rest of the API response or how you are rendering the API response in the beta search results or, and more likely a combination of the two.

However, I’ve yet to be able to find one.

mfairhurst · August 13, 2015, 2:02pm

Thanks for clarification and we will investigate how best to provide this documentation.

phillips_chris · February 27, 2017, 9:23am

I have just discovered this topic as we noticed that the registered office address for a particular company included the data ‘Finance’ which we weren’t seeing via the API.
On investigation we did see a data item ‘care_of’ which contained ‘FINANCE’, so there are two questions arising:

From previous discussion on this thread, should the data item be ‘care_of_name’ rather than ‘care_of’?
Why is the data in uppercase when using the API, it is shown in mixed case when querying via the Beta website?

The company we were looking at was TECHNIP PMC SERVICES LIMITED, Company number 05053002

frank · February 27, 2017, 3:31pm

The following, which appeared on the XML Forum 10 days ago, suggests that Care of / Care of Name data is to go in to the Premise field in the future and that the Care of field will eventually wither away. In light of this it may no longer need a name but if it does then the vast bulk of the date held is the names of businesses (accountants, solicitors, parents, etc.) so care_of_name would seem to be the right item name.

""Companies House has made a minor change to the way it stores addresses on the register.
The XML schema field which stores “care-of” information will no longer be used for new addresses and any “care-of” information is now being stored in the ”normal” address lines (usually in the premise field).

To avoid developers having to change their systems, Companies House has decided not to remove the field from relevant schemas, but to request customers to avoid using this field instead. This will have the same desired effect but without the effort and cost of a schema change.

We hope you agree with this solution and will comply with our request to avoid sending any data in “careofname” in the “ChangeRegisteredOfficeAddress” and “SAILAddress” elements of the schema. If you need to provide “care-of” address information, please use the remaining standard address lines but preferably the “Premise” field.

Thank you in advance for your co-operation.

SDN""

Personally, this change is far from welcome and I dread to think what end users will manage to do with an address that properly has more than three elements before the Post Town!!