Starting with Version 5.5.0, you can choose to preserve the input script of addresses from Belarus, China, Greece, Japan, Kazakhstan, Macedonia, Russia and Ukraine. To retain the input script in the output, you must set the PreferredScript parameter in parameter.xml to PRESERVE_INPUT.
If the input contains more than one script, AddressDoctor returns the address in the default script in the reference database.
If the input contains address elements that are not in the corresponding database, AddressDoctor copies such elements to the output in the same script the address was input.
Starting with Version 5.5.0, you can choose to retain locality aliases, also known as vanity names, in the validated output. You can set AliasStreet and AliasLocality values in the parameter.xml to define the handling of aliases for streets and localities.
If you want AddressDoctor to preserve the vanity name in the validated output, you must set the respective parameters to PRESERVE. If you want AddressDoctor to return the postal name in the validated output, set the respective parameters to OFF.
If you want to validated addresses in the Certified mode and generate output that conforms to the postal regulations of the country, you must ensure that the parameters are set to the default value OFFICIAL.
AddressDoctor version 5.5.0 and later supports only the new format of South Korean addresses. Similarly, the address data for South Korea has been migrated to the new format and is not compatible with previous versions of AddressDoctor.
However, AddressDoctor provides a database that matches land lot-based South Korean addresses with new formatted South Korean addresses. This translation has to be done on customer side and is not included in the validation progress.
This is an address example of the new South Korean address system:
Deongneung-ro 59-gil 4 (Street Name and House Number)
Dobong-gu, Seoul 132-919 (Locality 2 and Locality 1 and Postal Code)
Republic of Korea (Country)
Where possible, addresses are geocoded to building level. If this is not possible, they may be geocoded to the street, next fallback is center of a zip code or a locality. The detail level is written to the field OUT_GEOAccuracy. Possible values are:
The address was geocoded
The reference position of the building was geocoded
The Center of the street was geocoded
The Center of a suburb within the postcode was geocoded
The Center of the locality within the postcode was geocoded
The Center of the postcode was geocoded
There are a number of possible reasons, why an address was not geocoded. A value written into the field OUT_GEOStatus will provide more information.
0: Geo coordinates are not provided, because you have no more
geocoding transactions left.
1: Geo coordinates are not provided, because geo coding is not
available for this country.
2: Geo coordinates are not provided, because the Validation Status
was not V or C.
3: Geo coordinates are not provided, because geo coding
reported a no match.
4: Geo coordinates are provided. The field OUT_GEOAccuracy
describes the accuracy of the coordinates.
Access to AddressDoctor Cloud is available within minutes. Simply create a user account yourself and you can start right away.
AddressDoctor Cloud provides over 99.9% availability.
AddressDoctor Cloud accepts requests in the UTF-8 character set.
AddressDoctor Cloud will always return the data in a casing as described by the postal organizations of the destination country (unless the Capitalization parameter is set). So data for the UK or the US for instance, is always returned in upper case.
AddressDoctor Cloud will return an error 500 (server error) if the request is malformed. Most common reasons are wrong casing (all tags are case sensitive), incorrect casing of the URL embedded in the request or missing or incomplete tags such as a missing department (must be set to 0). Please make sure that your request is compatible with the WSDL available at validator5.addressdoctor.com/webservice5/v1/addressvalidation.asmx
Most likely your request is improperly encoded. AD cloud requires UTF-8 encoding. If you are not using a SOAP toolkit, please make sure that you are using the correct HTTP header (Content-Type: text/xml; charset=utf-8) and that the encoding of your data is proper.
AD cloud is case-sensitive. You need to deliver all Boolean values in all lower case like "false" or "true".
AddressDoctor will continue to support Web Service 4 after the launch of AddressDoctor Cloud. In order to allow flexible migration to AddressDoctor Cloud, AddressDoctor will continue to support Web Service 4 until June 30th 2015.
Pricing for AddressDoctor Cloud will remain the same as for the existing Web Service 4, current terms and conditions of Web Service 4 will remain valid for AddressDoctor Cloud as well. Purchased transactions for Web Service 4 can be used for AddressDoctor Cloud after the transition.
Using AddressDoctor Cloud requires the integration of new objects by the customer/partner. The documentation of AddressDoctor Cloud (shortly available) will contain all relevant object information. In order to simplify the transition from Web Service 4 to AddressDoctor Cloud, AddressDoctor will provide test accounts with free test transactions upon request. If you wish to work with a test account and to get access to the AddressDoctor Cloud testing environment, please contact your sales representative.