Name Search is relevant to our XML Output product (it cannot be done through our XML filing service).
This remains available as a chargeable product (a limited number of features remain chargeable and a small monthly subscription is required - name search is free however) - it is essential that anyone wishing to develop access to the Companies House XML Gateway has sound experience in developing software that uses HTTP and XML - the full technical interface specification, data schemas, prices, details of the information you can access through the Gateway and FAQ's can be found on our website via the following link.
You can access all relevant XML Gateway information here:
http://xmlgw.companieshouse.gov.uk/
Th specification of the authentication appears below – you will need to employ this method to access the Gateway. This method offers a secure route, employing MD5 encryption, into the Gateway. Failure to use it correctly will result in '502' error messages.
To allow you to test the XML Gateway service, I have included details of a test account for the XML gateway below.
Sender ID = XMLGatewayTestUserID
Password = XMLGatewayTestPassword
Please note whatever company information you request using these test credentials, we will return data relating to Millennium Stadium Plc only. Once you've confirm that you have successfully used the test account, and have provided us with examples of company/information data download, I will send you an application form for a live account, which you'll need to complete, sign and return for my private and personal attention to the address below.
I would add that the recently introduced API will fully replace the XML Gateway at a yet to be determined point in the future.
Companies House XML Gateway Output Service
Authentication
Authentication is performed through a SenderID and Password combination, transmitted to the gateway in an encoded form.
The encoding model used employs MD5 (http://www.faqs.org/ftp/rfc/pdf/rfc1321.txt.pdf or http://rfc.net/rfc1321.txt) hashing of the password with a one-time key. The algorithm is thus:
- The sender creates a unique Transaction ID (1..32 digits maximum, NUMERIC)
- The sender generates an MD5 digest of the concatenation of their senderID, password and transaction ID
- The sender submits the request and attaches
a. Their SenderID
b. Their Transaction ID
c. The MD5 digest
- The Gateway retrieves the password associated with the SenderID from its database
- The Gateway calculates an MD5 digest of the retrieved password and the transaction ID sent in the request
- The senders MD5 digest is compared with the Gateway's MD5 digest and if they match, the sender is authenticated
It is the action of the Transaction ID that makes this encoding one-time-only, therefore it is mandatory that this ID be incremental. You must use a higher number each time, do not use random strings it will cause the system to freeze and you will receive a 503 error message.
For example:
Given a SenderID of My_SenderID, a password of This_is_my_private_password and a transaction ID of 14456553, the MD5 digest of My_SenderIDThis_is_my_private_password14456553 would be generated - producing e999e113407884fa410fa2f53bc23952
The authentication information supplied by the sender to the Gateway would be:
• My_SenderID
• 14456553
• e999e113407884fa410fa2f53bc23952
Details of the XML elements used to transport these authentication details are described in the message envelope documentation.
Please note this MD5 hash process should not be used for XML Software Filing.
