Skip to main content

Clean Web Service

Overview

Clean Web Service provides the ability to clean, enrich and validate postal and email address details quickly and accurately via a hosted service.

As a back office tool, Clean Web Service is designed to clean and validate the address and email data you have collected from your customers, contacts and prospects. Our postal data is sourced from the official postal authorities of the relevant country, and is updated regularly. Email addresses are checked in real time against the email service providers. As such, Clean Web Service should be used regularly to ensure that your contact information is always correct and up-to-date.

Clean Web Service currently has two different versions. Version 1 is synchronous and can be used to clean postal addresses only. Version 2 is asynchronous and can clean postal addresses as well as validating email addresses.

CleanEnrichValidate

Clean Web Service cleans postal addresses from your contact database, including corrections and updates to the following:

  • Misspelled and mistyped information
  • Omitted information
  • Incorrect or outdated postal codes
  • Inconsistent and non-standard formatting
  • Standardisation with country-specific preferences

View Sample

DataPlus information can be appended to all cleaned postal addresses, allowing you to enrich the quality of your existing data. DataPlus includes the following information:

  • Contact telephone and fax numbers
  • Geographic coordinates
  • Government catchment areas
  • Business and employment information

 

Clean Web Service can also validate email addresses alongside cleaning postal addresses, including validating the following:

  • Mailbox or domain exists.
  • Mailbox is deliverable.
  • Mailbox is legitimate.
  • Domain is reachable.
  • Domain is disposable.

Note that email address validation is only available in version 2 of Clean Web Service.

View Sample

The extent to which contact data can be cleaned and enriched may vary depending on the quality of the information you provide.

Supported countries

For postal address cleaning, Clean Web Service supports the following countries:

  • Australia
  • Canada
  • France
  • Ireland
  • New Zealand
  • United Kingdom
  • United States of America
  • Singapore

Email address cleaning is not geographically restricted.

Licensing

When cleaning postal addresses, the countries, layouts and DataPlus that you have access to are determined by your unique licence agreement.

Email and postal address cleaning require separate licences.

If you need access to more features of Clean than your current licences provide, contact your Experian Account Manager or support.

Using the service

Requests are sent to Clean Web Service using the Simple Object Access Protocol (SOAP), and responses are sent back in the same way.

You can include a maximum of 1000 records (for V1) or 100,000 records (for V2) with each request. The sample pages show a method of splitting a larger collection of records into chunks.

Prerequisites

SOAP messages use the XML document format and are sent over HTTP (Clean Web Service uses HTTPS for secure communication).

To use Clean Web Service, you will require an understanding of SOAP as well as the ability to parse the address information from your existing contact database into the required SOAP formatting.

Analysing your cleaned data

Each response from Clean Web Service can include a unique match profile for every record that has been cleaned. Postal addresses are also accompanied by in-depth match codes.

Match codes describe the differences between the data supplied to the web service and the corresponding data that is sent back. They can be used to achieve an in-depth analysis of the changes that have been applied, and can also be used to programmatically select the postal addresses you want to add back into your database.

Match profiles are derived from match codes, and provide a basic overview of Clean's success in cleaning each postal address.

Sample pages

To facilitate easy integration, Experian supplies detailed, self-documenting C# sample code.

The sample pages allow you to send your address information to Clean Web Service via a .CSV formatted file.

Download Version 1 Sample Pages

Download Sample Addresses

Deploying The Sample Pages

The sample pages should be deployed as a .Net v2 application using IIS on a Microsoft Windows system.

1. Save the sample pages locally

Ensure the sample pages are stored in a location on the local machine.

For example, C:\Inetpub\wwwroot\CleanWSSample

2. Add Your Secure Token

  • In the location where you saved the sample pages, open Web.config in a text editor.
  • In the <appSettings> section, locate the following key and edit its value to equal your Experian SaaS Token:

    <add key="ExperianSaaSToken" value="#TOKEN#"/>

    If you do not have access to your token, contact support.

 3. Deploy as a .NET v2 application in IIS

  1. Open the Run dialog, type inetmgr, and press Enter.
    This will open IIS.
  2. Navigate to Default Web Site on the local machine.
  3. Right-click Default Web Site and select New > Add Virtual Directory.
  4. Using the dialog that appears, assign an alias to the new virtual directory, and enter the location that you saved the sample pages to in step 1.
    The sample pages will now appear as a directory under the Default Web Site, using the alias you chose.
  5. Select the newly-created virtual directory. Its contents display in the central pane.
  6. Double-click Directory Browsing and select Enable from the right-hand pane.
  7. In the Connections pane, select Application Pools.
  8. In the central pane, right-click the application pool you are using and select Basic Settings.
  9. In the dialog that appears, select .Net Framework v2.0.50727 from the .Net Framework version drop-down box.
  10. Click OK to save your settings.
  1. Open the Run dialog, type inetmgr, and press Enter.
    This will open IIS.
  2. Navigate to Default Web Site on the local machine.
    Right-click Default Web Site and select New > Virtual Directory...
    Using the wizard that appears, assign an alias to the new virtual directory, and enter the location that you saved the sample pages to in step 1.
    If you are prompted to select access permissions, retain the default settings and also select the Read box.

    The sample pages will now appear as a directory under the Default Web Site, using the alias you chose.

  3. Right-click the newly-created virtual directory, and select Properties.
    From the Properties dialog, select the following settings:
    • Under the Virtual Directory tab, click Create next to the Application Name field
    • Select the Directory Browsing box, and select Scripts Only from the Execute Permissions drop-down box.
    • Under the ASP.NET tab, select version 2.0.50727 from the drop-down box.
    • In the dialog that appears, type Default.aspx and click OK.
  4. Click OK to save and close the Properties dialog.
  1. Open the Run dialog, type inetmgr, and press Enter
    This will open IIS.
  2. Navigate to Default Web Site on the local machine.
  3. Right-click Default Web Site and select New > Add Virtual Directory.
  4. Using the dialog that appears, assign an alias to the new virtual directory, and enter the location that you saved the sample pages to in step 1.
    The sample pages will now appear as a directory under the Default Web Site, using the alias you chose.
  5. Select the newly-created virtual directory. Its contents display in the central pane.
  6. Double-click Directory Browsing and select Enable from the right-hand pane.
  7. In the Connections pane, select Application Pools.
  8. In the central pane, right-click the application pool you are using and select Basic Settings.
  9. In the dialog that appears, select .Net Framework v2.0.50727 from the .Net Framework version drop-down box.
  10. Click OK to save your settings.

4. Browse The Sample Pages

Right-click the virtual directory and select Browse (or, if you're using IIS 7.x, Manage Virtual Directory > Browse) to view the QAS Clean Web Service sample pages in your browser.

Using The Sample Pages

The sample pages include examples of the following workflows: 

Note that email address validation is only available in version 2 of Clean Web Service. As such the EmailValidate and CleanEnrichEmailValidate workflows are not available in version 1.

The CleanEnrich Workflow (postal addresses only)

Follow the CleanEnrich link from the sample pages to use a sample integration of this workflow.

  1. From the CleanEnrich page, select Browse and navigate to the CSV file that contains the postal address records you want to clean.
  2. Enter the following information in each field:
    • User Label [optional] – specify a name for this batch of records.
      This is used for tracking and reporting purposes, and is recommended for live usage.
    • Address Dataset – specify the three-letter ISO code of the dataset that Clean Web Service should match address records to by default.
    • Layout – specify the name of a layout that you want Clean Web Service to return your addresses in. The layout you specify must be compatible with the Address Dataset.
    • Reference Field [optional] – Specify 'True' to tell Clean Web Service not to process the first field of each address. This field will remain unaltered, and will be returned with the corresponding address in the response.
      This setting will be ignored if you use the Input Field Mappings setting.
    • Output Match Profile [optional] – specify 'True' to include an additional string at the start of every Record block (before the Match Code) which details the Match Profile for that address. 
    • Job Locale [optional] – tell the Clean which language the results should be sent in. Only Output Header and Output Match Profile are affected by this setting.
    • Input Field Mappings – specify the field types in your input file in the order that they appear.
      For example, 'Reference,Address,Address,Address' informs Clean that the first field contains a reference field and the next three fields comprise address information.
      If you use this setting, the Reference Field setting will be ignored.
    • Output Header [optional] – specify 'True' to include an additional Record block (before the first cleaned address record) which contains headers for each field in all subsequent Record blocks.
  3. Click Upload. On a new page, you'll see a summary of the parameters you specified.
    If you are happy with the summary shown, click Start Processing to send your file to Clean Web Service for processing.

The EmailValidate Workflow (email addresses only)

Follow the EmailValidate link from the sample pages to use a sample integration of this workflow.

  1. From the EmailValidate page, select Browse and navigate to the CSV file that contains the email address records you want to clean.
  2. Enter the following information in each field:
    • User Label [optional] – specify a name for this batch of records.
      This is used for tracking and reporting purposes, and is recommended for live usage.
    • Reference Field [optional] – Specify 'True' to tell Clean Web Service not to process the first field of each address. This field will remain unaltered, and will be returned with the corresponding address in the response.
      This setting will be ignored if you use the Input Field Mappings setting.
    • Job Locale [optional] – tell the Clean which language the results should be sent in. Only Output Header and Output Match Profile are affected by this setting.
    • Input Field Mappings – specify the field types in your input file in the order that they appear.
      For example, 'Reference,Email' informs Clean that the first field contains a reference field and the second field an email address.
      If you use this setting, the Reference Field setting will be ignored.
    • Output Header [optional] – specify 'True' to include an additional Record block (before the first cleaned address record) which contains headers for each field in all subsequent Record blocks.
  3. Click Upload. On a new page, you'll see a summary of the parameters you specified.
    If you are happy with the summary shown, click Start Processing to send your file to Clean Web Service for processing.

The CleanEnrichEmailValidate Workflow (postal and email addresses)

Follow the CleanEnrichEmailValidate link from the sample pages to use a sample integration of this workflow.

  1. From the CleanEnrichEmailValidate page, select Browse and navigate to the CSV file that contains the postal and email address records you want to clean. The records should be grouped together (each record should include a postal address and an email address).
  2. Enter the following information in each field:
    • User Label [optional] – specify a name for this batch of records.
      This is used for tracking and reporting purposes, and is recommended for live usage.
    • Address Dataset – specify the three-letter ISO code of the dataset that Clean Web Service should match address records to by default.
    • Layout – specify the name of a layout that you want Clean Web Service to return your postal addresses in. The layout you specify must be compatible with the Address Dataset.
    • Reference Field [optional] – Specify 'True' to tell Clean Web Service not to process the first field of each address. This field will remain unaltered, and will be returned with the corresponding address in the response.
      This setting will be ignored if you use the Input Field Mappings setting.
    • Output Match Profile [optional] – specify 'True' to include an additional string at the start of every Record block (before the Match Code) which details the Match Profile for that address. 
    • Job Locale [optional] – tell the Clean which language the results should be sent in. Only Output Header and Output Match Profile are affected by this setting.
    • Input Field Mappings – specify the field types in your input file in the order that they appear.
      For example, 'Reference,Address,Address,Address,Email' informs Clean that the first field contains a reference field and the next three fields comprise address information and the last field contains an email address.
      If you use this setting, the Reference Field setting will be ignored.
    • Output Header [optional] – specify 'True' to include an additional Record block (before the first cleaned address record) which contains headers for each field in all subsequent Record blocks.
  3. Click Upload. On a new page, you'll see a summary of the parameters you specified.
    If you are happy with the summary shown, click Start Processing to send your file to Clean Web Service for processing.

 

SOAP method reference

Version 1

Clean Web Service version 1 is synchronous so it therefore responds to just a single request, ProcessRecords.

Version 2

Clean Web Service version 2 is asynchonous so it therefore responds to two different requests; SubmitRecords and GetResults.

Request requirements

The GetResults (version 2) request should contain just the JobID section.

Each ProcessRecords (version 1) or SubmitRecords (version 2) request should contain the following sections:

SectionSupported TagsParametersDescription
records Record Fields Contains an array of records. Each line should occupy its own string object.
workflow     Informs Clean Web Service of the workflow to apply to the supplied records.
settings NamedValue Key
Value
Contains an array of settings presented as Key / Value pairs.

Endpoints

The method should be called in the body of a request sent to the following URL:

For Clean Web Service version 1 use:

https://api.experianmarketingservices.com/CleanWS/V1/BulkWebService.svc

 

For Clean Web Service version 2 use:

https://api.experianmarketingservices.com/CleanWS/V2/BulkWebService.svc

WSDL documents

For Clean Web Service version 1:

https://api.experianmarketingservices.com/CleanWS/V1/BulkWebService.svc?wsdl

For Clean Web Service version 2:

https://api.experianmarketingservices.com/CleanWS/V2/BulkWebService.svc?wsdl

records

This section is a wrapper used to provide Clean Web Service with an array of records for processing.

Note that email address validation is only available in version 2 of Clean Web Service.

SOAP Snippet

<ns:records>
  <ns:Record>
    <ns:Fields>
      <arr:string>REF001</arr:string>
      <arr:string>MetaFiction Ltd,14 Old St,London</arr:string>
      <arr:string>contact@metafiction.com</arr:string>
    </ns:Fields>
  </ns:Record>
</ns:records>

Comments

Each record is provided within a Record tag. Within this, the Fields block contains an array of strings, which each hold a different kind of field. In the example above, the Record contains the following strings:

<arr:string>REF001</arr:string>

This is a ReferenceField. It will not be processed, but will be included in the corresponding Record block in the response.

<arr:string>MetaFiction Ltd,14 Old St,London</arr:string>

This is a postal address string. All organisation information (if included) must appear as the first element of the postal address string.
The processing of organisation information is currently only supported when using the FRX AddressDataSet setting with a Layout that supports the processing of organisation data. For other datasets, these fields will be processed as normal address elements.
The remaining parts of the string are are 'normal' postal address elements.
When using the CleanEnrich workflow only, postal address records can be provided as multiple strings (for example, one address line per string).

<arr:string>contact@metafiction.com</arr:string>

This is an email address string.

You can use as many strings as required to provide the individual lines you have available for each record. Each successfully matched address will be cleaned and returned using the Layout you specify in the settings section.

You may include a maximum of 1000 Record tags within each request. The sample pages show a method of splitting a larger collection of records into 1000-record chunks.

Response

The response will also include a records section, containing Record tags which correspond to those you provided. In the event that a postal or email address cannot be matched, the corresponding strings will be empty.

The Fields which are returned will depend on the workflow you specify.

workflow

This section identifies the workflow which should be applied to the address records sent in a request.

Note that email address validation is only available in version 2 of Clean Web Service. As such the EmailValidate and CleanEnrichEmailValidate workflows are not available in version 1.

SOAP Snippet

<ns:workflow>CleanEnrich</ns:workflow>

Comments

This section must be used in every call. It informs Clean Web Service of the type of cleaning that should take place on each Record included in the request.

Values

The following workflows are available:

  • CleanEnrich
  • EmailValidate
  • CleanEnrichEmailValidate

settings

This section is a wrapper used to contain an array of settings particular to the workflow you have specified.

Note that email address validation is only available in version 2 of Clean Web Service. As such the EmailValidate and CleanEnrichEmailValidate workflows are not available in version 1.

Soap Snippet

<ns:settings>
  <ns:NamedValue>
    <ns:Key>UserLabel</ns:Key>
    <ns:Value>CleanTest</ns:Value>
  </ns:NamedValue>
  ...
</ns:settings>

Comments

This section must be used in every call. Each NamedValue tag represents a setting, which is communicated to Clean Web Service as a key/value pair.

Values

The settings available for each workflow are as follows:

CleanEnrich

KeyValue

UserLabel
[optional]

Any. This should be a useful label used to identify the batch of records being sent in the request.

InputFieldMappings
[optional]*

Used to inform Clean of the order the input field types take in each Record block.
For example, a value of 'Reference,Address' informs Clean that the first field in each Record block contains a reference field and the second field comprises address information.
Supported values:
Reference (a reference field that will not be processed)
Address (comma-separated postal address lines)

AddressDataSet

The three-letter ISO code of the country that Clean Web Service should match address records to (for example, GBR).

This must be one of the three-letter dataset codes listed here.

Layout

The name of a layout (for example, Standard). The layout specified here must be compatible with the AddressDataSet.
A list of default layouts available for each country can be found here.
Additional layouts may be added using the Clean Application user interface, or by contacting your Experian Data Quality Account Manager.

ReferenceField
[optional]*

True or False (defaults to False). If True, Clean Web Service will not process the first field of each address. This field will remain unaltered, and will be returned with the corresponding address in the response.

OutputHeader
[optional]

 

True or False (defaults to False). If True, Clean will include an additional Record block (before the first cleaned address record) which contains headers for each field in all subsequent Record blocks.
The fields that make up the header block will have values such as 'Match Profile', 'Match Code', 'CleanedAddress1', 'CleanedAddress2' and so on.

OutputMatchProfile
[optional]

True or False (defaults to False). If True, Clean will include an additional string at the start of every Record block (before the Match Code) which details the Match Profile for that address. For more information, see Match Profiles.

JobLocale
[optional]

 
Indicates the language which results should be sent in. Defaults to en-GB. Only OutputHeader and OutputMatchProfile are affected by this setting.

If an invalid language code is supplied, the Job will fail. Unsupported but valid language codes will default to en-GB. Supported values: en-US, en-GB or fr-FR.

 * the InputFieldMappings and ReferenceField settings are equivalent and cannot be used together (InputFieldMappings takes precedence). If you include a reference field in your data, you must use one of these settings.

EmailValidate

KeyValue

UserLabel
[optional]

Any. This should be a useful label used to identify the batch of records being sent in the request.

InputFieldMappings
[optional]*

Used to inform Clean of the order the input field types take in each Record block.
For example, a value of 'Reference,email' informs Clean that the first field in each Record block contains a reference field and the second field contains an email address.
Supported values:
Reference (a reference field that will not be processed)
Email (an email address)

OutputHeader
[optional]

 

True or False (defaults to False). If True, Clean will include an additional Record block (before the first cleaned record) which contains headers for each field in all subsequent Record blocks.
The fields that make up the header block will have values such as 'CleanedEmail', and 'EmailMatchCode'.

JobLocale
[optional]

 
Indicates the language which results should be sent in. Defaults to en-GB. Only OutputHeader and OutputMatchProfile are affected by this setting.

If an invalid language code is supplied, the Job will fail. Unsupported but valid language codes will default to en-GB. Supported values: en-US, en-GB or fr-FR.

 

CleanEnrichEmailValidate

KeyValue

UserLabel
[optional]

Any. This should be a useful label used to identify the batch of records being sent in the request.

InputFieldMappings
[optional]*

Used to inform Clean of the order the input field types take in each Record block.
For example, a value of 'Reference,Address,Email' informs Clean that the first field in each Record block contains a reference field, the second field comprises address information and the third field contains an email address.
Supported values:
Reference (a reference field that will not be processed)
Address (comma-separated postal address lines)
Email (an email address)

AddressDataSet

The three-letter ISO code of the country that Clean Web Service should match address records to (for example, GBR).

This must be one of the three-letter dataset codes listed here.

Layout

The name of a layout (for example, Standard). The layout specified here must be compatible with the AddressDataSet.
A list of default layouts available for each country can be found here.
Additional layouts may be added using the Clean Application user interface, or by contacting your Experian Data Quality Account Manager.

OutputHeader
[optional]

 

True or False (defaults to False). If True, Clean will include an additional Record block (before the first cleaned address record) which contains headers for each field in all subsequent Record blocks.
The fields that make up the header block will have values such as 'Match Profile', 'Match Code', 'CleanedAddress1', 'CleanedAddress2', 'CleanedEmail' and so on.

OutputMatchProfile
[optional]

True or False (defaults to False). If True, Clean will include an additional string at the start of every Record block (before the Match Code) which details the Match Profile for that address. For more information, see Match Profiles.

JobLocale
[optional]

 
Indicates the language which results should be sent in. Defaults to en-GB. Only OutputHeader and OutputMatchProfile are affected by this setting.

If an invalid language code is supplied, the Job will fail. Unsupported but valid language codes will default to en-GB. Supported values: en-US, en-GB or fr-FR.

Response

The response will include Record tags corresponding to those you send in records section of the request, any optional fields you request using the settings above and (for workflows which include postal addresses) any DataPlus fields that are included in the Layout you specify (where a such fields can be found for a given address).


KeyValueUserLabel[optional]Any. This should be a useful label used to identify the batch of records being sent in the request.InputFieldMappings[optional]*Used to inform Clean of the order the input field types take in each Record block.For example, a value of 'Reference,Address' informs Clean that the first field in each Record block contains a reference field and the second field comprises address information.Supported values:Reference (a reference field that will not be processed)Address (comma-separated postal address lines)AddressDataSet

Headers and authorisation

An authorisation token must be passed to Clean Web Service in the HTTP header. A secure token will be provided to you when you purchase a licence to use Clean Web Service. This token will grant you access to the functionality and data you are licensed to use.

All requests sent to Clean Web Service must include an HTTP header containing:

  • The content type (including the action parameter shown below).
  • Your authorisation token.
    A secure authorisation token will be provided to you when you purchase a licence to use Clean Web Service. This token will grant you access to the functionality and data you are licensed to use.
  • Other standard parameters, such as Accept-Encoding and Content-Length.

Sample:

POST https://api.experianmarketingservices.com/CleanWS
HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://www.qas.com/BulkWebService/2011-04/IBulkWebService/ProcessRecords"
auth-token: 001a100-a10a-a101a-101a-1010a1010a10
Content-Length: 2194
Host: api.experianmarketingservices.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

SOAP samples

Clean Web Service currently has two different versions. Version 1 is synchronous and can be used to clean postal addresses only. Version 2 is asynchronous and can clean both postal and email addresses.

Version 1

Version 1 of Clean Web Service is synchronous and can only be used to clean postal addresses. As such the only available workflow is the CleanEnrich workflow.

As Version 1 is synchronous, it means that you only have to send one request. You will then receive a response once the cleaning has been completed, this response will contain your cleaned postal address records.

This section identifies the workflow which should be applied to the address records sent in a request.

SOAP snippet

<ns:workflow>CleanEnrich</ns:workflow>

Comments

This section must be used in every call. It informs Clean Web Service of the type of cleaning that should take place on each Record included in the request.

V1 sample requests and responses

ProcessRecords

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ns="http://www.qas.com/BulkWebService/2011-04"
xmlns:arr=" http://schemas.microsoft.com/2003/10/Serialization/Arrays">
  <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing" >
    <wsa:Action>http://www.qas.com/BulkWebService/2011-04/IBulkWebService/ProcessRecords</wsa:Action>
    <wsa:To>https://api.experianmarketingservices.com/CleanWS/V1/BulkWebService.svc</wsa:To>
  </soap:Header>
  <soap:Body>
    <ns:ProcessRecords>
      <ns:records>
        <ns:Record>
          <ns:Fields>
            <arr:string>REF001</arr:string>
            <arr:string>MetaFiction Ltd,14 Old St,London</arr:string>
          </ns:Fields>
        </ns:Record>
        <ns:Record>
          <ns:Fields>
            <arr:string>REF002</arr:string>
            <arr:string>10 Downing St,London</arr:string>
          </ns:Fields>
        </ns:Record>
      </ns:records>
      <ns:workflow>CleanEnrich</ns:workflow>
      <ns:settings>
        <ns:NamedValue>
          <ns:Key>UserLabel</ns:Key>
          <ns:Value>CleanTest</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>AddressDataSet</ns:Key>
          <ns:Value>GBR</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>Layout</ns:Key>
          <ns:Value>StandardWithCoordinates</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>InputFieldMappings</ns:Key>
          <ns:Value>Reference,Address</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>OutputHeader</ns:Key>
          <ns:Value>True</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>OutputMatchProfile</ns:Key>
          <ns:Value>True</ns:Value>
        </ns:NamedValue>
        <ns:NamedValue>
          <ns:Key>JobLocale</ns:Key>
          <ns:Value>en-GB</ns:Value>
        </ns:NamedValue>
      </ns:settings>
    </ns:ProcessRecords>
  </soap:Body>
</soap:Envelope>

 

HTTP Header

All requests sent to Clean Web Service must include an HTTP header containing your authorisation token and other parameters.

Note that email address validation is only available in version 2 of Clean Web Service.

Requests to Clean Web Service use a standard SOAP envelope which declares a bulk web service namespace (the xmlns:ns attribute). SOAP headers should be empty; authorisation tokens are sent in the HTTP header.

The contents of the request body are sent to Clean Web Service in a ns:ProcessRecords SOAP object. The following sections must be included:

ns:records

In this request, two Records are sent to Clean Web Service for processing. The Fields parameters each contain strings, identified as string objects.

In this example, the first field of each Record is a reference field. Including a reference field makes comparisons easier, and will allow us to easily insert the processed address back into our source database. To ensure that reference fields are not processed by Clean Web Service, we map them using the InputFieldMappings setting (see below).

The next field of each Record are address fields (again, we map the order of the fields using the InputFieldMappings setting).

Any blank fields are sent as empty string objects.

ns:workflow

The workflow section specifies the CleanEnrich workflow, meaning that the address record should be matched against postal address records and cleaned. The results of the cleaning process can be seen in the Sample ProcessRecordsResponse.

ns:settings

The settings section contains several NamedValues, each made up of a Key / Value pair:

  • The UserLabel key assigns the label 'CleanTest' to this batch of records.
  • The AddressDataSet key tells Clean Web Service that GBR data should be used to match records.
  • The Layout key tells Clean Web Service to provide the cleaned addresses using the StandardWithCoordinates layout. This is a custom layout similar to Standard, except that it includes Eastings and Northings.

A list of predefined layouts available for each country can be found here.

Additional layouts may be added using the Clean Application user interface, or by contacting your Experian Data Quality Account Manager.

  • The InputFieldMappings key tells Clean Web Service that the first field in each row is for reference purposes only, the second field contains address data. The order of components in this setting must correspond to the order of the fields in each Record block.
  • The OutputHeader key tells Clean to include an additional Record block at the beginning of the response (before the first cleaned record) which contains headers for each field in all subsequent Record blocks.
  • The OutputMatchProfile key tells Clean to include an additional string in each Record block which details the Match Profile for the address. For more information, see Match Profiles.
  • The JobLocale key tells the Clean which language the results should be sent in. Only OutputHeader and OutputMatchProfile are affected by this setting. Supported values are en-US, en-GB or fr-FR.

Each of these keys are covered in more detail in the SOAP Method Reference section.

ProcessRecordsResponse

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://www.qas.com/BulkWebService/2011-04/IBulkWebService/ProcessRecordsResponse</a:Action>
  </s:Header>
  <s:Body>
    <ProcessRecordsResponse xmlns="http://www.qas.com/BulkWebService/2011-04">
      <ProcessRecordsResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <AdditionalInformation>
          <NamedValue>
            <Key>TotalRecords</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>RecordsSubmitted</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>ProcessingTime</Key>
            <Value>8328.3915ms</Value>
          </NamedValue>
          <NamedValue>
            <Key>BatchVersion</Key>
            <Value>7.30</Value>
          </NamedValue>
          <NamedValue>
            <Key>DatasetName</Key>
            <Value>GBR</Value>
          </NamedValue>
          <NamedValue>
            <Key>DataSetVintage</Key>
            <Value>21/02/2014</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR_RecordsCleaned</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR_RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsCleaned</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
        </AdditionalInformation>
        <JobId>1225f4e3-f20f-4766-8334-9ad9b923aa41</JobId>
        <Message>Records processed successfully.</Message>
        <Records>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>MatchProfile</b:string>
              <b:string>MatchCode</b:string>
              <b:string>ReferenceField</b:string>
              <b:string>CleanedAddress1</b:string>
              <b:string>CleanedAddress2</b:string>
              <b:string>CleanedAddress3</b:string>
              <b:string>CleanedAddress4</b:string>
              <b:string>CleanedAddress5</b:string>
              <b:string>CleanedAddress6</b:string>
              <b:string>CleanedAddress7</b:string>
            </Fields>
          </Record>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>Good Premise Partial</b:string>
              <b:string>P923004020220000100000000000:GBR</b:string>
              <b:string>REF001</b:string>
              <b:string>14-18 Old Street</b:string>
              <b:string />
              <b:string>LONDON</b:string>
              <b:string/>
              <b:string>EC1V 9BH</b:string>
              <b:string>05320</b:string>
              <b:string>01822</b:string>
            </Fields>
          </Record>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>Good Premise Partial</b:string>
              <b:string>P923000000220000000000000000:GBR</b:string>
              <b:string>REF002</b:string>
              <b:string>10 Downing Street</b:string>
              <b:string/>
              <b:string>LONDON</b:string>
              <b:string/>
              <b:string>SW1A 2AA</b:string>
              <b:string>05300</b:string>
              <b:string>01799</b:string>
            </Fields>
          </Record>
        </Records>
        <Status>Completed</Status>
      </ProcessRecordsResult>
    </ProcessRecordsResponse>
  </s:Body>
</s:Envelope>

Note that email address validation is only available in version 2 of Clean Web Service.

Responses are sent from Clean Web Service in a ProcessRecordsResult SOAP object. The following sections are included:

AdditionalInformation

The first section of each response is AdditionalInformation, which contains information regarding the data used to process and clean the records. This information is contained within NamedValues, which are in turn made up of Key / Value pairs:

  • the DataSetVintage key details the age of the data which was used to match address records. Results of address cleaning may vary slightly depending on the vintage of data that is used, as newer vintages contain updated data. Clean Web Service always uses the latest data as soon as it is available.
  • the [...]RecordsProcessed keys detail how many address records Clean Web Service was able to match against each cleaning process or postal address dataset. In the example above, we can see that our postal address records were successfully processed against the core GBR dataset (CLEAN-GBR) and the GBR grid reference dataset (CLEAN-GBR-GBRGRD). This corresponds to the AddressDataset and Layout settings sent as part of the ProcessRecords request.
  • the [...]RecordsCleaned keys detail how many records were successfully cleaned using each postal address dataset. In the example above, we can see that our postal address records were cleaned using both datasets which were used to process them (the GBR dataset, explicitly specified in the ProcessRecords request using the AddressDataset setting, and the GBR-GBRGRD dataset and some of its DataPlus sets, implicitly included by the Layout setting which was specified in the ProcessRecords request).

    If any records could not be cleaned successfully against the GBR dataset, Clean Web Service would not attempt to enrich the record by appending GBR-GBRGRD DataPlus information to it. In this situation, neither the RecordsProcessed or RecordsCleaned values for any datasets would be incremented.

For more information, see processing and cleaning.

  • The TotalRecords, RecordsProcessed and RecordsSubmitted keys details the total number of records in the response, the number of records that were successfully processed and the number of records that were originally sent in the corresponding request.
  • The ProcessingTime key details the time Clean took to process the request, in milliseconds.

JobId

A unique JobId is included in every response. If you need to contact Experian regarding one of your jobs, this can be used for tracing purposes.

Message

The Message field contains general information about the completed job, including any errors that may have been encountered. In this example, we can see that all records were processed successfully.

Records

Each response contains cleaned Records – one for each Record you sent in a ProcessRecords request. Each Record's Fields are represented as string objects.

If you set the OutputHeader setting to True, the first Record will contain headers for each field in all subsequent Record blocks (for example, 'Match Profile', 'ReferenceField', 'CleanedAddress1').

In all subsequent Record blocks in this example:

  • The first string is the address match profile (if this was requested using the OutputMatchProfile setting). Match profiles define Clean's level of success in terms of cleaning this specific postal address Record. Match profiles are closely related to match codes.
  • The next string is always the address match code. In the example above, each match code begins with P or R and ends with GBR, which tells us that Clean Web Service successfully matched the postal address records to addresses in the United Kingdom.
  • In this example, the next string is the reference field. If used, this is always the same as the reference field you supplied.
  • The next five strings (in this example) are separate address lines, organised according to the Layout setting specified in the request.
  • The next two strings contain two DataPlus elements, which are implicitly specified by the Layout setting of the request (in this case, this is the Easting and Northing coordinates of the addresses).

Status

The Status field contains a short summary of the completed job. In this example, this tells us that our request was completed without errors or timeouts.

Version 2

Version 2 of Clean Web Service is asynchronous and can be used to clean and validate both postal and email addresses. As such all three workflows are available.

As Version 2 is asynchronous it allows you to send a request for your records to be cleaned without having to wait for them all to be processed. Instead you send a second request to check the status of the job. This request can be sent at any interval until the job has been completed. You will then receive a result response with your cleaned and validated records.

The section below identifies the three workflows available to be sent in a request for Clean Web Service version 2.

SOAP snippet

<ns:workflow>CleanEnrich</ns:workflow>

Comments

This section must be used in every call. It informs Clean Web Service of the type of cleaning and/or validating that should take place on each Record included in the request.

V2 sample requests and responses

SubmitRecords

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ns="http://www.qas.com/BulkWebService/2014-10"
xmlns:ns1="http://www.qas.com/BulkWebService/2011-04"
xmlns:arr=" http://schemas.microsoft.com/2003/10/Serialization/Arrays">
  <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing" >
    <wsa:Action>http://www.qas.com/BulkWebService/2014-10/IBulkWebService/SubmitRecords</wsa:Action>
    <wsa:To>https://api.experianmarketingservices.com/CleanWS/V2/BulkWebService.svc</wsa:To>
  </soap:Header>
  <soap:Body>
    <ns:SubmitRecords>
      <ns:records>
        <ns1:Record>
          <ns1:Fields>
            <arr:string>REF001</arr:string>
            <arr:string>MetaFiction Ltd,14 Old St,London</arr:string>
            <arr:string>contact@metafiction.com</arr:string>
          </ns1:Fields>
        </ns1:Record>
        <ns1:Record>
          <ns1:Fields>
            <arr:string>REF002</arr:string>
            <arr:string>10 Downing St,London</arr:string>
            <arr:string></arr:string>
          </ns1:Fields>
        </ns1:Record>
      </ns:records>
      <ns:workflow>CleanEnrichEmailValidate</ns:workflow>
      <ns:settings>
        <ns1:NamedValue>
          <ns1:Key>UserLabel</ns1:Key>
          <ns1:Value>CleanTest</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>AddressDataSet</ns1:Key>
          <ns1:Value>GBR</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>Layout</ns1:Key>
          <ns1:Value>Standard</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>InputFieldMappings</ns1:Key>
          <ns1:Value>Reference,Address,Email</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>OutputHeader</ns1:Key>
          <ns1:Value>True</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>OutputMatchProfile</ns1:Key>
          <ns1:Value>True</ns1:Value>
        </ns1:NamedValue>
        <ns1:NamedValue>
          <ns1:Key>JobLocale</ns1:Key>
          <ns1:Value>en-GB</ns1:Value>
        </ns1:NamedValue>
      </ns:settings>
    </ns:SubmitRecords>
  </soap:Body>
</soap:Envelope>

HTTP Header

  • All requests sent to Clean Web Service must include an HTTP header containing your authorisation token and other parameters.
  • This example shows usage of the CleanEnrichEmailValidate workflow only, but changing the value of the workflow setting and omitting certain record fields and settings will make this example compatible with other workflows too.

Requests to Clean Web Service use a standard SOAP envelope which declares a bulk web service namespace (the xmlns:ns attribute). SOAP headers should be empty; authorisation tokens are sent in the HTTP header.

The contents of the request body are sent to Clean Web Service in a ns:SubmitRecords SOAP object. The following sections must be included:

ns:records

In this request, two Records are sent to Clean Web Service for processing. The Fields parameters each contain three strings, identified as string objects.

In this example, the first field of each Record is a reference field. Including a reference field makes comparisons easier, and will allow us to easily insert the processed address back into our source database. To ensure that reference fields are not processed by Clean Web Service, we map them using the InputFieldMappings setting (see below).

The next two fields of each Record are address and email fields (again, we map the order of the fields using the InputFieldMappings setting).

Any blank fields are sent as empty string objects. In this case, the second Record  does not contain an email field, so this is left blank.

ns:workflow

The workflow section specifies the CleanEnrichEmailValidate workflow, meaning that the address record should be matched against postal address records and cleaned, and the email record should be cleaned and validated in real time. The results of the cleaning process can be seen in the sample response.

ns:settings

The settings section contains several NamedValues, each made up of a Key / Value pair:

  • The UserLabel key assigns the label 'CleanTest' to this batch of records.
  • The AddressDataSet key tells Clean Web Service that GBR data should be used to match records.
  • The Layout key tells Clean Web Service to provide the cleaned addresses using the StandardWithCoordinates layout. This is a custom layout similar to Standard, except that it includes Eastings and Northings.

A list of predefined layouts available for each country can be found here.

Additional layouts may be added using the Clean Application user interface, or by contacting your Experian Data Quality Account Manager.

  • The InputFieldMappings key tells Clean Web Service that the first field in each row is for reference purposes only, the second field contains address data and the third field contains an email address. The order of components in this setting must correspond to the order of the fields in each Record block.
  • The OutputHeader key tells Clean to include an additional Record block at the beginning of the response (before the first cleaned record) which contains headers for each field in all subsequent Record blocks.
  • The OutputMatchProfile key tells Clean to include an additional string in each Record block which details the Match Profile for the address. For more information, see Match Profiles.
  • The JobLocale key tells the Clean which language the results should be sent in. Only OutputHeader and OutputMatchProfile are affected by this setting. Supported values are en-US, en-GB or fr-FR.

Each of these keys are covered in more detail in the SOAP Method Reference section.

SubmitRecordsResponse

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://www.qas.com/BulkWebService/2011-04/IBulkWebService/ProcessRecordsResponse</a:Action>
    <a:RelatesTo>uuid:a8bdb736-3663-4a72-98d4-104226bc5f13</a:RelatesTo>
  </s:Header>
  <s:Body>
    <SubmitRecordsResponse xmlns="http://www.qas.com/BulkWebService/2014-10">
      <SubmitRecordsResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <AdditionalInformation xmlns:b="http://www.qas.com/BulkWebService/2011-04">
          <JobId>1225f4e3-f20f-4766-8334-9ad9b923aa41</JobId>
          <Message>Job in progress.</Message>
          <Records>
            xmlns:b="http://www.qas.com/BulkWebService/2011-04"/>
            <Status>Processing</Status>
          </SubmitRecordsResult>
    </SubmitRecordsResponse>
  </s:Body>
</s:Envelope>

Responses are sent from Clean Web Service in a SubmitRecordsResult SOAP object. The following sections are included:

RelatesTo

This section reflects an ID that was passed by the caller in the header of the request that generated the response.

JobId

A unique JobId is included in every response. If you need to contact Experian regarding one of your jobs, this can be used for tracing purposes.

Message

The Message field contains general information about the job, including any errors that may have been encountered. In this example, we can see that the job is still in progress.

Status

The Status field contains a short summary of the job. In this example, this tells us that our request is processing.

GetResults

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing" >
    <wsa:Action>http://www.qas.com/BulkWebService/2014-10/IBulkWebService/GetResults</wsa:Action>
    <wsa:To>https://api.experianmarketingservices.com/CleanWS/V2/BulkWebService.svc</wsa:To>
  </soap:Header>
  <soap:Body>
    <ns:GetResults>
      <ns:jobId>1225f4e3-f20f-4766-8334-9ad9b923aa41</ns:jobId>
    </ns:GetResults>
  </soap:Body>
</soap:Envelope>

 

HTTP Header

  • All requests sent to Clean Web Service must include an HTTP header containing your authorisation token and other parameters.

Requests to Clean Web Service use a standard SOAP envelope which declares a bulk web service namespace (the xmlns:ns attribute). SOAP headers should be empty; authorisation tokens are sent in the HTTP header.

The contents of the request body are sent to Clean Web Service in a ns:GetResults SOAP object. The only section to be included is:

JobId

The JobId is the only section for this request and is required in order to get the results of the job we submitted. The JobId can be found in the relevant SubmitRecordsResponse. If you need to contact Experian regarding one of your jobs, this can be used for tracing purposes.

GetResultsResponse

Version 2 of Clean Web Service is asynchronous and so therefore when sending the GetResults request there are two possible responses.

Response 1

If the results are not ready, you will get a response similar to the one below to explain that the job is still in progress. 

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://www.qas.com/BulkWebService/2011-04/IBulkWebService/ProcessRecordsResponse</a:Action>
    <a:RelatesTo>uuid:a8bdb736-3663-4a72-98d4-104226bc5f13</a:RelatesTo>
  </s:Header>
  <s:Body>
    <GetResultsResponse xmlns="http://www.qas.com/BulkWebService/2014-10">
      <GetResultsResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <AdditionalInformation xmlns:b="http://www.qas.com/BulkWebService/2011-04">
          <b:NamedValue>
            <b:Key>ProcessingTime</b:Key>
            <b:Value>32141.61ms</b:Value>
            <JobId>1225f4e3-f20f-4766-8334-9ad9b923aa41</JobId>
            <Message>Job in progress.</Message>
            <Records>
              xmlns:b="http://www.qas.com/BulkWebService/2011-04"/>
              <Status>Processing</Status>
            </GetResultsResult>
    </GetResultsResponse>
  </s:Body>
</s:Envelope>

Response 2

If the job has completed then you will receive a response similar to the one below.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://www.qas.com/BulkWebService/2014-10/IBulkWebService/GetResultsResponse</a:Action>
  </s:Header>
  <s:Body>
    <GetResultsResponse xmlns="http://www.qas.com/BulkWebService/2014-10">
      <GetResultsResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <AdditionalInformation xmlns:b="http://www.qas.com/BulkWebService/2011-04">
          <NamedValue>
            <Key>TotalRecords</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>RecordsSubmitted</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>ProcessingTime</Key>
            <Value>8328.3915ms</Value>
          </NamedValue>
          <NamedValue>
            <Key>BatchVersion</Key>
            <Value>7.30</Value>
          </NamedValue>
          <NamedValue>
            <Key>DatasetName</Key>
            <Value>GBR</Value>
          </NamedValue>
          <NamedValue>
            <Key>DataSetVintage</Key>
            <Value>21/02/2014</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR_RecordsCleaned</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR_RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsCleaned</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsProcessed</Key>
            <Value>2</Value>
          </NamedValue>
          <NamedValue>
            <Key>CLEAN-EMAILVALIDATE_RecordsProcessed</Key>
            <Value>1</Value>
          </NamedValue>
        </AdditionalInformation>
        <JobId>1225f4e3-f20f-4766-8334-9ad9b923aa41</JobId>
        <Message>Records processed successfully.</Message>
        <Records>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>MatchProfile</b:string>
              <b:string>MatchCode</b:string>
              <b:string>ReferenceField</b:string>
              <b:string>CleanedAddress1</b:string>
              <b:string>CleanedAddress2</b:string>
              <b:string>CleanedAddress3</b:string>
              <b:string>CleanedAddress4</b:string>
              <b:string>CleanedAddress5</b:string>
              <b:string>CleanedAddress6</b:string>
              <b:string>CleanedAddress7</b:string>
              <b:string>CleanedEmail</b:string>
              <b:string>EmailMatchCode</b:string>
            </Fields>
          </Record>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>Good Premise Partial</b:string>
              <b:string>P923004020220000100000000000:GBR</b:string>
              <b:string>REF001</b:string>
              <b:string>14-18 Old Street</b:string>
              <b:string />
              <b:string>LONDON</b:string>
              <b:string/>
              <b:string>EC1V 9BH</b:string>
              <b:string>05320</b:string>
              <b:string>01822</b:string>
              <b:string>contact@metafiction.com</b:string>
              <b:string>Verified</b:string>
            </Fields>
          </Record>
          <Record>
            <Fields xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
              <b:string>Good Premise Partial</b:string>
              <b:string>P923000000220000000000000000:GBR</b:string>
              <b:string>REF002</b:string>
              <b:string>10 Downing Street</b:string>
              <b:string/>
              <b:string>LONDON</b:string>
              <b:string/>
              <b:string>SW1A 2AA</b:string>
              <b:string>05300</b:string>
              <b:string>01799</b:string>
              <b:string/>
              <b:string>Unreachable</b:string>
            </Fields>
          </Record>
        </Records>
        <Status>Completed</Status>
      </GetResultsResult>
    </GetResultsResponse>
  </s:Body>
</s:Envelope>

Responses are sent from Clean Web Service in a GetResultsResult SOAP object. The following sections are included:

This example shows a response for the CleanEnrichEmailValidate workflow only; responses from other workflows are similar, but omit values specific to postal or email addresses.

RelatesTo

This section reflects an ID that was passed by the caller in the header of the request that generated the response. If this was not present in the request then this section will not appear in the response.

AdditionalInformation

The first section of each response is AdditionalInformation, which contains information regarding the data used to process and clean the records. This information is contained within NamedValues, which are in turn made up of Key / Value pairs:

    • the DataSetVintage key details the age of the data which was used to match address records. Results of address cleaning may vary slightly depending on the vintage of data that is used, as newer vintages contain updated data. Clean Web Service always uses the latest data as soon as it is available.
    • the [...]RecordsProcessed keys detail how many address records Clean Web Service was able to match against each cleaning process or postal address dataset. In the example above, we can see that our postal address records were successfully processed against the core GBR dataset (CLEAN-GBR) and the GBR grid reference dataset (CLEAN-GBR-GBRGRD). This corresponds to the AddressDataset and Layout settings sent as part of the request. We can also see that one email address was successfully validated (CLEAN-EMAILVALIDATE). This is as expected as we only provided one email address.

If any records could not be cleaned successfully against the GBR dataset, Clean Web Service would not attempt to enrich the record by appending GBR-GBRGRD DataPlus information to it. In this situation, neither the RecordsProcessed or RecordsCleaned values for any datasets would be incremented.

  • the [...]RecordsCleaned keys detail how many records were successfully cleaned using each postal address dataset. In the example above, we can see that our postal address records were cleaned using both datasets which were used to process them (the GBR dataset, explicitly specified in the request using the AddressDataset setting, and the GBR-GBRGRD dataset and some of its DataPlus sets, implicitly included by the Layout setting which was specified in the request).

    If any records could not be cleaned successfully against the GBR dataset, Clean Web Service would not attempt to enrich the record by appending GBR-GBRGRD DataPlus information to it. In this situation, neither the RecordsProcessed or RecordsCleaned values for any datasets would be incremented.

For more information, see this definition of postal address processing and cleaning.

  • The TotalRecords, RecordsProcessed and RecordsSubmitted keys details the total number of records in the response, the number of records that were successfully processed and the number of records that were originally sent in the corresponding request.
  • The ProcessingTime key details the time Clean took to process the request, in milliseconds.

JobId

A unique JobId is included in every response. If you need to contact Experian regarding one of your jobs, this can be used for tracing purposes.

Message

The Message field contains general information about the completed job, including any errors that may have been encountered. In the first example, we can see that the job is still in progress. In the second example, we can see all records were processed successfully.

Records

Each completed job response contains cleaned Records – one for each Record you sent in a SOAP request. Each Record's Fields are represented as string objects.

If you set the OutputHeader setting to True, the first Record will contain headers for each field in all subsequent Record blocks (for example, 'Match Profile', 'ReferenceField', 'CleanedAddress1', 'CleanedEmail').

In all subsequent Record blocks in this example:

  • The first string is the postal address match profile (if this was requested using the OutputMatchProfile setting). Match profiles define Clean's level of success in terms of cleaning this specific postal address Record. Match profiles are closely related to match codes.
  • The next string is always the postal address match code. In the example above, each match code begins with P or R and ends with GBR, which tells us that Clean Web Service successfully matched the postal address records to addresses in the United Kingdom.
  • In this example, the next string is the reference field. If used, this is always the same as the reference field you supplied.
  • The next five strings (in this example) are separate address lines, organised according to the Layout setting specified in the request.
  • The next two strings contain two DataPlus elements, which are implicitly specified by the Layout setting of the request (in this case, this is the Easting and Northing coordinates of the addresses).
  • The next string is the email address. If no email address is supplied in the request, or if the email address has been found to be invalid, this string will be blank.
  • The string after the email address is the email match code. Email match codes define Clean's level of success in terms of cleaning this specific email address.

Status

The Status field contains a short summary of the completed job. In this example, this tells us that our request was completed without errors or timeouts.

Workflows

The following workflows are available to be used in Clean Web Service.

V1 supports the CleanEnrich workflow only.

 

 

CleanEnrich (postal addresses only)

Required settings

 The AddressData and Layout settings must be used.

Processing overview

For each Record, the following processing will take place:

  • Match – the address is compared against the postal database for the AddressDataSet which is specified in the settings section.
  • Clean – If a match is found, any missing elements of the address are added, and any incorrect or out of date elements are fixed.
  • Enrich – Any DataPlus fields which are included in the Layout you specified in the settings section are appended to your Records.

Response overview

The first two strings in each of the response's Record tags contain the match profile (if you specified in the settings section that match profiles should be returned) and the match code for the record. These correspond to the quality of the match and the changes made to the record.

The next set of strings contain each line of the address, according to the Layout you specified in the settings section. Any blank strings indicate that a field is not used. For example, many addresses do not require the state/county field.

The final set of strings contain any DataPlus fields which are included in the Layout that you requested in the settings section.

An additional string will contain a reference field, if you requested one to be included, either by specifying it in the InputFieldMappings, or by setting ReferenceField to True.

EmailValidate (email addresses only)

Required settings

The InputFieldMappings setting must be used.

Processing overview

For each Record, the following process will take place:

    • Validate – the email address is validated in real time against the relevant service provider.

Response overview

The first string in each of the response's Record tags contain the email match profile (if you specified in the settings section that match profiles should be returned). This corresponds to the quality of the match and the changes made to the email address.

One of the following strings contains the cleaned and validated email address, if available. If the email address could not be validated, this string will be empty.

If you included a reference field, this will also be included as a string.

The order which the last two strings are returned in depends on the value you supply for the InputFieldMappings setting.

CleanEnrichEmailValidate (postal and email addresses)

Required settings

The InputFieldMappingsAddressDataSet and Layout settings must be used.

Processing overview

For each Record, the following processing will take place:

  • Match – each postal address is compared against the postal database for the AddressDataSet which is specified in the settings section.
  • Clean – If a matching postal address is found, any missing elements of the address are added, and any incorrect or out of date elements are fixed. At the same time, each email address is checked for common errors, such as mistyped elements of the email address, and corrected.
  • Enrich – Any DataPlus fields which are included in the postal address Layout you specified in the settings section are appended to your Records.
  • Validate – Email address is validated in real time against the relevant service provider.

Response overview

The first two strings in each of the response's Record tags contain the match profile (if you specified in the settings section that match profiles should be returned) and the match code for the record. These correspond to the quality of the match and the changes made to the record.

One of the next set of strings contain the cleaned postal address, according to the Layout you specified in the settings section. Any blank address elements indicate that a field is not used. For example, many addresses do not require the state/county field.

Another set of strings contain any DataPlus fields which are included in the Layout that you requested in the settings section.

Another string contains the cleaned and validated email address, if available. If the email address could not be validated, this string will be empty.

If you included a reference field, this will also be included as a string.

With the exception of the match profiles and match code (which are always returned first) the order which the strings are returned in depends on the value you supply for the InputFieldMappings setting.

Processing and cleaning

When using a workflow which supports postal address cleaning, each successful request to Clean Web Service will result in a response which includes an AdditionalInformation object, containing fields similar to those shown below.

<AdditionalInformation>
  <NamedValue>
    <Key>DataSetVintage</Key>
    <Value>21/02/2014</Value>
  </NamedValue>
  <NamedValue>
    <Key>BatchVersion</Key>
    <Value>7.30</Value>
  </NamedValue>
  <NamedValue>
    <Key>DatasetName</Key>
    <Value>GBR</Value>
  </NamedValue>
  <NamedValue>
    <Key>TotalRecords</Key>
    <Value>62</Value>
  </NamedValue>
  <NamedValue>
    <Key>RecordsProcessed</Key>
    <Value>60</Value>
  </NamedValue>
  <NamedValue>
    <Key>RecordsSubmitted</Key>
    <Value>62</Value>
  </NamedValue>
  <NamedValue>
    <Key>CLEAN-GBR_RecordsCleaned</Key>
    <Value>56</Value>
  </NamedValue>
  <NamedValue>
    <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsCleaned</Key>
    <Value>52</Value>
  </NamedValue>
  <NamedValue>
    <Key>CLEAN-GBR_RecordsProcessed</Key>
    <Value>60</Value>
  </NamedValue>
  <NamedValue>
    <Key>CLEAN-GBR-GBRGRD_Dataplus_RecordsProcessed</Key>
    <Value>52</Value>
  </NamedValue>
</AdditionalInformation>

It is important to understand the meaning of these values, as they directly affect the amount you are charged for using Clean Web Service. Whether you are charged for the number of records processed or cleaned depends on your individual licence agreement.

RecordsProcessed

When cleaning data, this is the number of records which were successfully processed (those that achieve a Match Success indicator between K and R).

When enriching data, this is the number of records for which DataPlus values were returned from a particular DataPlus set. Charges are made for each DataPlus set used, no matter how many individual DataPlus fields are returned. DataPlus sets are identified by their six-letter code. In the example above, the GBR Grid DataPlus set (GBRGRD) has been used.

In the example above, we can see that:

  • 62 records were sent to Clean Web Service (as shown by the value of RecordsSubmitted).
  • Of these, 60 records were processed against the GBR AddressDataset, which tells us that two records could not be matched successfully.
  • Of these, 52 records were processed against the GBRGRD DataPlus set. See RecordsCleaned below for an explanation of this.

The reason(s) for any record remaining unmatched can be determined by its individual match code, which will be the only non-blank string for any unmatched records.

RecordsCleaned

When cleaning data, this is the number of records which were cleaned with high or intermediate confidence (those that achieve a Confidence Level of 5 or 9).

When enriching data, this is the number of records which were cleaned with high confidence (those that achieve a Confidence Level of 9 only), for which at least one DataPlusField from the indicated DataPlus set was appended.

In the example above, we can see that:

  • 56 records were cleaned against the GBR AddressDataset, which tells us that every record which was matched successfully was also matched with intermediate or high confidence.
  • Of these, 52 records were cleaned against the GBRGRD DataPlus set. One possible explanation of this is that four of the records were matched with only intermediate confidence; it is also possible that no grid information could be found for these records. Analysis of the individual match codes will help to determine which is the most likely.

Address datasets and predefined layouts

The following datasets are supported by Clean Web Service when cleaning postal addresses. 

Each dataset relates to addresses in a particular country, but some countries are served by more than one dataset. In these cases one of the datasets (AUG for Australia) contains geocoding DataPlus, which is absent from other datasets.

The countries, datasets and DataPlus elements you can use depend on the licences available to you.

In each request:

  • the three-letter code of one of these datasets must be used as the value of the AddressDataset setting.
  • the name of a layout supported by this dataset must be used as the value of the Layout setting. Select a country from the list to view the predefined layouts available for it.

You can add your own custom layouts using the Clean Application user interface. Custom layouts can include address lines from one of the datasets you are licensed to use, and any of the DataPlus sets you are licensed to use from the same dataset.

Sample request


...
    <ns:settings>
        <ns:NamedValue>
            <ns:Key>AddressDataSet</ns:Key>
            <ns:Value>"Dataset code e.g. AUG"</ns:Value>
         </ns:NamedValue>
        <ns:NamedValue>
            <ns:Key>Layout</ns:Key>
            <ns:Value>"Layout name e.g. Geocoded National Address File (G-NAF)"</ns:Value>
        </ns:NamedValue>
    </ns:settings>
...

Australia

Using the Australia address dataset, Australian addresses can be cleaned against one of the following predefined layouts:

Note that selecting a certified layout ensures that the results returned by Clean are completely in line with Australia Post’s AMAS address matching rules. This may result in a lower matching rate due to the stricter nature of these rules.

AMAS Certified (Postal Address File)

Addresses are returned in an AMAS-Certified layout, and include unique Delivery Point Identifiers (DPIDs). Address barcoding is available.

This layout qualifies for AMAS reports.

LineAddress Element(s)Example
1 [Automatic Line 1] 7 Alexander Street
2 [Automatic Line 2]  
3 [Locality] [State Code] [Postcode] HAMILTON SOUTH NSW 2303
4 Delivery Point Identifier (DPID) 59172312
LineDataPlus ElementExample
5 Barcode Sort Plan Number 017
6 Customer Barcode 1301011230012102100102333123313022013

Certified status

This address layout is Certified by your local carrier. To retain its Certified status, you may not edit the address lines or remove existing DataPlus elements. However, by creating a new layout based on this one, you may add DataPlus elements and retain the benefits of Certification, as long as the DataPlus elements you add are not included as part of a mailing address.

Standard Clean (Postal Address File)

Addresses are returned in a non-certified layout. Address barcoding is available.

LineAddress Element(s)Example
1 [Automatic Line 1] 7 Alexander Street
2 [Automatic Line 2]  
3 [Locality] [State Code] [Postcode] HAMILTON SOUTH NSW 2303

Australia G-NAF

Using the Australia G-NAF address dataset, Australian addresses can be cleaned against the following predefined layout:

Geocoded National Address File (G-NAF)

Addresses are optimised for geocoding. A range of geocoding DataPlus items are available.

LineAddress Element(s)Example
1 [Automatic Line 1] 7 Alexander Street
2 [Automatic Line 2]  
3 [Locality][State Code][Postcode] HAMILTON SOUTH NSW 2303

Canada

Using the Canada address dataset, Canadian addresses can be cleaned against one of the following predefined layouts:

4 Line Standard

Similar to Standard, but supplied as a four-line layout.

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Municipality] KINGSTON
3 [Province code] ON
4 [Postal Code] K7M 7T5

5 Line Standard

Similar to Standard, but supplied as a five-line layout.

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Automatic Line 2] 14 Greenview Dr
3 [Municipality] KINGSTON
4 [Province code] ON
5 [Postal Code] K7M 7T5

5 Line Submitted

Similar to Submitted, but supplied as a five-line layout.

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Automatic Line 2] 14 Greenview Dr
3 [Municipality] KINGSTON
4 [Province code] ON
5 [Postal Code] K7M 7T5

When using Submitted layouts, all capitalisation sent in the request is retained.

Certified

A three-line layout. The language of the province is retained, but fully capitalised (for example, "ONTARIO").

This layout qualifies for SOA reports.

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Automatic Line 2] 14 Greenview Dr
3 [Municipality][Submitted Province]*[Province code] KINGSTON ONTARIO K7M 7T5

* The language and formatting of the province sent in the request is retained by the [Submitted Province] address element. When using the Certified layout, this element is always capitalised.

Certified status

This address layout is Certified by your local carrier. To retain its Certified status, you may not edit the address lines or remove existing DataPlus elements. However, by creating a new layout based on this one, you may add DataPlus elements and retain the benefits of Certification, as long as the DataPlus elements you add are not included as part of a mailing address.

Standard

A three-line layout. The two-letter province code replaces the information supplied (for example, "ON").

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Automatic Line 2] 14 Greenview Dr
3 [Municipality][Province code][Postal Code] KINGSTON ON K7M 7T5

Submitted

A three-line layout. The language and capitalisation of the province is retained (for example, "Ontario").

LineAddress Element(s)Example
1 [Automatic Line 1] The Greenview
2 [Automatic Line 2] 14 Greenview Dr
3 [Municipality][Submitted Province]*[Postal Code] KINGSTON Ontario K7M 7T5

* The language and formatting of the province sent in the request is retained by the [Submitted Province] address element. When using Submitted layouts, capitalisation is also retained.

France

Using the France address dataset, French addresses can be cleaned against one of the following predefined layouts:

AFNOR

This layout is identical to the AFNOR with business names layout, but an organisation name is not required. A maximum of six lines (fields) will be returned, but the first line will be left blank if no organisation information is supplied.

LineAddress Element(s)Example
1 [AFNOR line 1] * TRADUCTEURS NAÏFS
2 [AFNOR line 2] † APPARTEMENT 37, BÂTIMENT 4
3 [AFNOR line 3] † LIEU DIT AU BALIVERNES
4 [Number] [Number Extension] [Street] 10A BOULEVARD GEORGES CLEMENCEAU
5 [PO Box] [Submitted Locality] NORD-PAS DE CALAIS
6 [Postal Code] [Town] [CEDEX Office] 62226 CALAIS CEDEX

* Company or recipient’s name, or blank
† Details such as flat, floor, staircase, entrance, building, and secondary street

This layout is identical to the 'AFNOR with business names' layout, but an organisation name is not required. A maximum of six lines (fields) will be returned, but the first line will be left blank if no organisation information is supplied.

AFNOR with business names

This layout is compliant with AFNOR standard XPZ10-011 (May 1997). Each address will be returned on a maximum of six lines (fields), with a maximum of 38 characters per line.

To use this layout successfully you should supply business names in one or more fields, and map the columns they occupy as Organisation.

LineAddress Element(s)Example
1 [AFNOR line 1] * TRADUCTEURS NAÏFS
2 [AFNOR line 2] † APPARTEMENT 37, BÂTIMENT 4
3 [AFNOR line 3] † LIEU DIT AU BALIVERNES
4 [Number] [Number Extension] [Street] 10A BOULEVARD GEORGES CLEMENCEAU
5 [PO Box] [Submitted Locality] NORD-PAS DE CALAIS
6 [Postal Code] [Town] [CEDEX Office] 62226 CALAIS CEDEX

* Company or recipient’s name, or blank
† Details such as flat, floor, staircase, entrance, building, and secondary street

This layout is compliant with AFNOR standard XPZ10-011 (May 1997). Each address will be returned on a maximum of six lines (fields), with a maximum of 38 characters per line.

Standard

This layout is similar to the AFNOR layout, but the last line contains the addresses' département and postal code, in that order (rather than the postal code, town and CEDEX office). Organisation names are not required or expected.

LineAddress Element(s)Example
1 [AFNOR line 1] * TRADUCTEURS NAÏFS
2 [AFNOR line 2] † APPARTEMENT 37, BÂTIMENT 4
3 [AFNOR line 3] † LIEU DIT AU BALIVERNES
4 [Number] [Number Extension] [Street] 10A BOULEVARD GEORGES CLEMENCEAU
5 [PO Box] [Submitted Locality] NORD-PAS DE CALAIS
6 [Département] [Postal Code] PAS-DE-CALAIS 62226

* Company or recipient’s name, or blank
† Details such as flat, floor, staircase, entrance, building, and secondary street

This layout is similar to the AFNOR layout, but the last line contains the addresses' département and postal code, in that order (rather than the postal code, town and CEDEX office). Organisation names are not required or expected.

Ireland

Using the Ireland address dataset, Irish addresses can be cleaned against one of the following predefined layouts:

Resident Preferred

This layout returns the format of addresses commonly preferred by residents, as indicated by the address elements that are present in the input address. For example, 'Co Dublin' will be retained if present in the input address, rather than being replaced with an official equivalent (such as 'Dublin 22').

LineAddress Element(s)Example
1 [Automatic Line 1]  Meneen
2 [Automatic Line 2]  Achadh Ghobhair
3 [Automatic Line 3]  Cathair na Mart
4 [Automatic Line 4]  Maigh Eo
5 [Automatic Line 5]  

Resident Preferred Gaelic

Returns the format of addresses commonly preferred by residents (as above), but with address elements returned in their Gaelic format (where available).

LineAddress Element(s)Example
1 [Automatic Line 1]  Meneen
2 [Automatic Line 2]  Achadh Ghobhair
3 [Automatic Line 3]  Maigh Eo
4 [Automatic Line 4]  
5 [Automatic Line 5]  

Standard

This is the official An Post format of a given address. This format varies depending on whether a building group is present in the address.

LineAddress Element(s)Example
1 [Automatic Line 1] Meneen
2 [Automatic Line 2] Aghagower
3 [Automatic Line 3] Westport
4 [Automatic Line 4] Co Mayo
5 [Automatic Line 5]  

Gaelic

This is the official An Post format of a given address (as above), but with address elements returned in their Gaelic format (where available).

LineAddress Element(s)Example
1 [Automatic Line 1] Meneen
2 [Automatic Line 2] Achadh Ghobhair
3 [Automatic Line 3] Maigh Eo
4 [Automatic Line 4]  
5 [Automatic Line 5]  

New Zealand

Using the New Zealand address dataset, New Zealand addresses can be cleaned against the following predefined layout:

SendRight Certified (Postal Address File)

The city of the address is returned as the [Locality] element. Address identification and coding DataPlus information is available.

This layout qualifies for SOA and SOA Log reports.

LineAddress Element(s)Example
1 [Automatic Line 1] Villa 105
2 [Automatic Line 2] Summerset Retirement Village
3 [Automatic Line 3] 15 Aotea Drive, Aotea
4 [City][Postcode] Porirua 5024

Certified status

This address layout is Certified by your local carrier. To retain its Certified status, you may not edit the address lines or remove existing DataPlus elements. However, by creating a new layout based on this one, you may add DataPlus elements and retain the benefits of Certification, as long as the DataPlus elements you add are not included as part of a mailing address.

Singapore

Using the Singapore address dataset, Singaporean addresses can be cleaned against the following predefined layout:

Standard

A standard address format for Singapore addresses.

LineAddress Element(s)Example
1 [Automatic Line 1] Window Delivery 2
2 [Building Number][Street] 2 Raffles Link
3 [Floor][Unit][Building Name] #03-04 Marina Bayfront
4 [Locality][Postal code] Singapore 039392

United Kingdom

Using the United Kingdom address dataset, British addresses can be cleaned against one of the following predefined layouts:

Royal Mail Standard

Similar to the Standard layout, but a Delivery Point Suffix is supplied as an additional address field. DataPlus fields are not available using this layout.

LineAddress Element(s)Example
1 [Automatic Line 1] 26 Stokesby Road
2 [Automatic Line 2]  
3 [Town] Chessington
4 [County] Surrey
5 [Postcode] KT9 2DU
6 [Delivery Point Suffix]* 1A

* A Delivery Point Suffix, in conjunction with a postcode, can be used to programmatically create a RM4SCC (Royal Mail 4-state) barcode.

Standard

A standard address format for British addresses.

LineAddress Element(s)Example
1 [Automatic Line 1] 26 Stokesby Road
2 [Automatic Line 2]  
3 [Town] Chessington
4 [County] Surrey
5 [Postcode] KT9 2DU

United States

Using the United States address dataset, United States addresses can be cleaned against one of the following predefined layouts:

Note that selecting a certified layout enables CASS-accredited output and ensures the results returned by Clean conform to the CASS rules, including the mandatory use of Delivery Point Validation (DPV). This may result in a lower matching rate due to the stricter nature of these rules.

4-line Non-Certified

Identical to the Non-Certified layout, but supplied as a four-line layout.

LineAddress Element(s)Example
1 [Automatic Line 1] The White House
2 [City Name] Washington
3 [State Code] DC
4 [ZIP Code] [ZIP +4 Code] 20500 0003

5-line Certified

Identical to the Certified layout, but supplied as a five-line layout.

This layout qualifies for CASS reports.

Note that if you encounter a seed address whilst using Clean, your account will be DPV locked and you will no longer be able to use certified cleaning.

LineAddress Element(s)Example
1 [Automatic Line 1] The White House
2 [Automatic Line 2] Pennsylvania Ave Nw
3 [City Name] Washington
4 [State Code] DC
5 [ZIP Code] [ZIP +4 Code] 20500 0003
LineDataPlus ElementExample
6 DPV: DPV Footnotes AAN1
7 DPV: DPV Confirmation Indicator D
8 DPV: CMRA Confirmation Indicator N
9 DPV: Seed Address Indicator  
10 DPV: Vacant Address Indicator N
11 DPV: No-Mail Indicator N

DPV (Delivery Point Validation) DataPlus elements return information about the validity of address records in accordance with USPS guidelines.

Note that if you encounter a seed address whilst using Clean, your account will be DPV locked and you will no longer be able to use certified cleaning.

Certified status

This address layout is Certified by your local carrier. To retain its Certified status, you may not edit the address lines or remove existing DataPlus elements. However, by creating a new layout based on this one, you may add DataPlus elements and retain the benefits of Certification, as long as the DataPlus elements you add are not included as part of a mailing address.

5-line Non-Certified

Identical to the Non-Certified layout, but supplied as a five-line layout.

LineAddress Element(s)Example
1 [Automatic Line 1] The White House
2 [Automatic Line 2] Pennsylvania Ave Nw
3 [City Name] Washington
4 [State Code] DC
5 [ZIP Code] [ZIP +4 Code] 20500 0003

5-line Secondary Non-Certified

As above, but supplied as a five-line layout including a secondary building number (such as an apartment number).

LineAddress Element(s)Example
1 [Automatic Line 1] The White House
2 [Secondary number] Apt 34
3 [City Name] Washington
4 [State Code] DC
5 [ZIP Code] [ZIP +4 Code] 20500 0003

6-line County Non-Certified

As above, but supplied as a six-line layout including the county name.

LineAddress Element(s)Example
1 [Automatic Line 1] The White House
2 [Automatic Line 2] Pennsylvania Ave Nw
3 [City Name] Washington
4 [County Name] Washington D.C.
5 [State Code] DC
6 [ZIP Code] [ZIP +4 Code] 20500 0003

Certified

A standard three-line layout. Delivery Point Validation (DPV) is available, as well as LACSLink and SuiteLink data.

This layout qualifies for CASS reports.

Note that if you encounter a seed address whilst using Clean, your account will be DPV locked and you will no longer be able to use certified cleaning.

LineAddress Element(s)Example
1 [Building/firm name] [Urbanization] The White House
2 [Primary number] [Automatic Line 2] 1600 Pennsylvania Ave Nw
3 [City Name] [State Code] [ZIP Code] [ZIP +4 Code] Washington DC 20500 0003
LineDataPlus ElementExample
6 DPV: DPV Footnotes AAN1
7 DPV: DPV Confirmation Indicator D
8 DPV: CMRA Confirmation Indicator N
9 DPV: Seed Address Indicator  
10 DPV: Vacant Address Indicator N
11 DPV: No-Mail Indicator N

DPV (Delivery Point Validation) DataPlus elements return information about the validity of address records in accordance with USPS guidelines.

Note that if you encounter a seed address whilst using Clean, your account will be DPV locked and you will no longer be able to use certified cleaning.

Certified status

This address layout is Certified by your local carrier. To retain its Certified status, you may not edit the address lines or remove existing DataPlus elements. However, by creating a new layout based on this one, you may add DataPlus elements and retain the benefits of Certification, as long as the DataPlus elements you add are not included as part of a mailing address.

Non-Certified

Identical to the Certified layout, but DPV, LACSLink and SuiteLink data is not available.

LineAddress Element(s)Example
1 [Building/firm name] [Urbanization] The White House
2 [Primary number] [Automatic Line 2] 1600 Pennsylvania Ave Nw
3 [City Name] [State Code] [ZIP Code] [ZIP +4 Code] Washington DC 20500 0003

Specialised font files

Some Clean DataPlus sets return values which can only be properly interpreted using specialised font files.

If you plan to use any of the DataPlus sets listed below, you should download the associated font files in order to use the data as intended.

CountryDataPlus SetDownload
Australia Customer Barcode AUS4STSTE.TTF
Singapore Barcode RM4SCC.TTF
United Kingdom Barcode RM4SCC.TTF
United States of America USPS POSTNET Barcode POSTNET.TTF

To use these font files, first install them in your operating system.

In your database or word processor, set the barcode portion of your cleaned addresses to display in the appropriate barcode font. You should make sure the barcodes are displayed correctly on screen before printing. For example, a RM4SCC-format barcode looks like this before and after the font is applied:

(BX11LT1AI)   

Match profiles

In the Results Summary, each of the processed results are grouped into different categories depending on the level of success that Clean was able to match them with a correct postal or email address.

Each of the possible Match Profiles (postal addresses) and Email Match Codes (email addresses) are defined below.

All addresses (except French)

If you are cleaning addresses from any country other than France, the possible Match Profiles are as follows.

Match ProfileMeaningRelated Match Codes
Verified Correct Clean verified the input address as a good-quality match to a complete address. No corrections or formatting changes were necessary.


Success: R or Q
Confidence: 9
Generic Infobit: 00000040

Good Match Clean verified the input address as a good-quality match to a complete address, although minor corrections or formatting changes may have been applied.

Success: R or Q
Confidence: 9

Good Premise Partial Clean was not able to find a full match to a correct address, but found a good match to premise level by excluding organisation or sub-premise details.

Success: O or P
Confidence: 9
Generic Infobit: 00000002

Tentative Match Clean found a match to a complete address, but the overall differences between the input and Cleaned addresses are significant enough to reduce Clean's confidence in the match.

Success: R or Q
Confidence: 5

Multiple Matches Clean found more than one correct address which matched the input address. This generally means that no single address could be matched with high confidence. Success: M or N
Poor Match Clean found a match to an address, but with low confidence. This often means that the Cleaned address is not deliverable.

Success: R or Q
Confidence: 0

Partial Match Clean was unable to find a full correct address which matched the input address. This often occurs when the property number is missing from the input address. Success: O or P
Foreign Address Clean could not find a matching address because the input address referred to a country other than that which you ran your clean against. Success: C
Unmatched Clean was unable to match the input address to any correct address. For more detail, see the Match Success Indicator assigned to this address. Success: ABDK or L

French addresses

If you are cleaning French addresses, the possible Match Profiles match the La Poste Match Categories, as follows.

Match ProfileMeaningRelated Match Codes
Address already correct The address was deemed to be correct as supplied. All address elements were supplied on the correct lines, and in the correct format.

Confidence: 9
Country Infobit: 10000000

Address corrected or modified The address was matched with a high degree of confidence, but some corrections were made. For example, spelling or formatting may have been corrected, or missing address elements may have been added.

Confidence: 9
Country Infobit: 20000000

Address to be checked A match was found, but Clean cannot be certain that the returned address is the correct one. For example, the returned address may be very different from the input, important address elements may have been changed, or other equally good matches may exist in the data. The match has been downgraded to intermediate confidence, and the user should check the returned address manually.

Confidence: 5
Country Infobit: 40000000

No match No address could be returned at all. Unmatched addresses will return low confidence. Confidence: 0

Emails

If you are cleaning email addresses, the possible Email Match Codes are as follows:

Email Match CodeMeaning
Verified Mailbox exists, is reachable, and not known to be illegitimate or disposable.
Undeliverable Mailbox or domain does not exist, or mailbox is full, suspended or disabled.
Unknown We were unable to conclusively verify or invalidate this address.
Unreachable Domain has no reachable mail exchangers.
Illegitimate Seed, spamtrap, black hole, technical role account or inactive domain.
Disposable Domain is administered by a disposable email provider (e.g. Mailinator).

Match codes

Match codes describe the differences between input postal addresses and their corresponding cleaned addresses. They can be used to achieve an in-depth analysis of the changes that have been applied. They can also be used to programmatically select addresses to be added back into your database.

If you have processed postal address data, Match Codes are always included as the first field of each address in your Cleaned Address File. See an example of what this looks like.

An example match code is broken into its component sections above. 

Match success indicator

The Match Success Indicator is always one upper case letter and describes how well the input address matched to the output address returned by Clean.

Letters A-D mean that the address was not processed. The reason for this is indicated by the letter returned.

A Unprocessed Results could not be returned for the input address. This reflects an internal processing issue, and should not occur during normal usage.
B Blank This means that Clean could either find no data in the input address or too insignificant an amount of data to return an address.
C Country not available This match letter is returned when your input address contains the name of an unsupported country.
D Unidentified Country A match letter of D is assigned to the address record when Clean is unable to ascertain the country of origin.

The Information Bit sections of unprocessed addresses will always be empty (represented by a series of uninterrupted zeros).

Letters K-R mean that the address was successfully processed. The quality of the match is indicated by the letter returned.

K No address or postcode could be derived This match letter is used when Clean cannot find any data which matches your input address. For example, if you processed 42 Durlston Square, Clean would return a K match. This is because there are no matching street names within the United Kingdom, and Clean has no other information (such as a locality or postcode) to search on.
L Postcode found, but no address could be derived This match letter is returned if Clean derives a valid postcode from your input address information but did not find a matching address
M Multiple addresses found, but no postcode

Clean returns this match letter if the input address matches more than one address in the dataset. For example, the address below returns four matches:
146 High Street, Cambridge
As the address exists in the localities of Sawston, Cottenham, Chesterton and Landbeach, Clean cannot determine what is the desired match. As all four potential matches have different postcodes and no single postcode can be returned, Clean marks the address as an M match.

N Multiple addresses found with postcode This type of match is returned when Clean finds more than one matching address within a postcode.
O Partial address found, but no postcode

In this case Clean has found a partial address which matched your input. However, it cannot return a full postcode with it, because the partial address is covered by more than one postcode. This might occur if your input address has a missing or invalid property number. Clean cannot determine the correct property number, and returns as much of the address as it can. For example, in this address, number 70 does not exist:
70 Glebe Road, Long Ashton, Bristol
As no postcode is included in the input address, Clean does not know which of two possible postcodes to return, and produces this output:
Glebe Road, Long Ashton, Bristol

P Partial address found with postcode

Clean has found a partial address which matches your input. In addition, either the input postcode was valid, or Clean has managed to find a single postcode for the partial address. For example, if this address is searched on:
Tooting Bec Rd, London
Clean is able to add a postcode and state code, but the lack of property number prevents the return of a full address.

Q Full address found, but no postcode This occurs when Clean finds a full address which matches your input data, but cannot find a full postcode to go with it.
R Full address and postcode found

In this case, Clean has made a full match, either by simply verifying a correct input address, or by locating a full address from the partial input data. The following example returns an R match:
14 Carnaby St, London
However, an R match only signifies that a full address and postcode have been returned; it does not necessarily mean that the address is the one you want. You can gauge the likelihood of a correct match from the match confidence level.

Confidence level

The Confidence Level is always one single digit and indicates the level of confidence which Clean has in each match. There are three possible values:

9 High confidence Indicates that the output address matches the input address.
5 Intermediate confidence

Indicates that the less important rules were not satisfied, such as:

  • There must be some form of match with a street name.
  • If none of the place elements have been matched, the postcode must be matched.
0 Low confidence

Indicates that the essential matching rules were not satisfied. These rules include such conditions as:

  • There must be an input element defining the location of the address (a town, a postcode etc).
  • There must be an element defining property information.

Postal code action

Postal Code Action indicates any action that Clean has performed on the postcode. There are four possible values:

0 No action was taken (usually because no postcode was found, or the address was not processed).
1 The existing postcode was already correct.
2 A postcode has been added.
3 The existing postcode has been corrected.

Address action

Address Action indicates any action that Clean has performed on the address, other than the postcode. There are three possible values:

0 No action was taken (usually because the input address could not be matched to a correct address).
2 The existing address was enhanced. No significant information has been removed, but some information has been added.
3 A partial or complete address was returned. The amount of address is signified by the match success indicator.

Generic information bits

Generic Information Bits are used to communicate general changes to your address information.

Information Bits are added together to make up a hexadecimal code. The example above is a combination of 00002000 (change of key premises number) and 00000020 (non-trivial cleaning).

Information BitDescription
10000000 The elements in the input address were not in the expected order. For example, the address "7 Old Town, SW4 0JT, London", would be changed to place the postcode at the end of the address.
20000000 Preferred matching rules were not satisfied, and the match will be, at best, intermediate confidence.
40000000 The address has been marked with, at best, intermediate confidence because close matching rules have been satisfied.
80000000 Conditional formatting has taken place. Some address elements in the specified output format were not present in the matched address record and have been replaced with equivalent address elements.
01000000 Extra numbers were found in the address. An example might be "Flat 2, 12 10, Abbeville Road, London".
A full match was achieved, (Flat 2, 10 Abbeville Road, London, SW4 9NJ) but the additional number(s) (i.e. "12" in the above example) may reduce the confidence level to Intermediate.
02000000 Additional text between a number and its expected adjacent component has been found, for example between a property number and a street name. The confidence level has been reduced to Intermediate.
04000000 No place element was found in the address, so the confidence level may be reduced.
08000000 An item associated with a number is missing. For example, in the address "4, South Marston, Swindon, SN3 4XX" should include the street name "Ash Gardens" after the building number.
00100000 One or more essential matching rules were not satisfied, so the confidence level has been reduced to low.
00200000 A timeout has occurred and the address has not been matched. This error should occur extremely rarely; if you encounter this problem, please let us know.
00400000 The input address was a superset of the address found by Clean.
For example, the input address "Village Arcade, 5 Hillcrest Road, Pennant Hill, NSW, 2120" contains more information than the official version, which does not contain the "Village Arcade" element.
00800000 The input address contained leading information which was not matched in the return address.
For example, the input address "8 Piermark Drive, PO Box 1116, London, SE1 7AG" contains more information than the official version, which does not contain the "8 Piermark Drive" element.
00010000 There was ambiguity in the supplied range in the input address.
For example, the address "138-140 Tooting Bec Road, London" has an ambiguous range because there are premises numbered 138, 139 and 140 on Tooting Bec Road and the input address cannot be matched to a specific property.
00020000 A street descriptor has been added or has changed. For example, given "4 Oamaru Street, Devizes", the correct descriptor "Way", is returned instead of "Street".
00040000 Additional text in the input address was too significant to ignore. This returns intermediate confidence.
00080000 There was an error in the input street name that Clean has amended.
00001000 There was an error in an input place name. This has been corrected by Clean.
00002000 Clean has added or changed a key premises number or range compared with the input address.
00004000 An exact street level match cannot be made, and there is more than one possibility of matching by changing either the street or the place. Due to this ambiguity at the street level, Clean cannot safely match the input address.
00008000 A name was used to secure an address match.
00000100 The address line settings of the currently configured layout are of an insufficient width to contain each address element. Widen the address lines to ensure that the address elements are not truncated.
00000200 Complete address element(s) are unable to fit on the address line. Widen the address lines to ensure that all of the address elements are visible.
00000400 Clean failed to generate one or more non-address items. Address matching is unaffected.
00000800 When in enhanced cleaning mode, Clean cannot fill the unmatched address elements back into the database. To resolve this, widen the address lines or add additional lines.
00000010 Address elements have been moved to the right or downwards to allow unmatched elements to be incorporated, to produce an enhanced address.
00000020 Clean has determined that the supplied address has been non-trivially cleaned. This means that spelling may have been corrected, capitalisation changed, or the input address elements could have been reformatted in some way. Note that quotes and spaces are ignored during Clean's comparison process.
00000040 Key input address elements were judged effectively correct as supplied, although note that the output address's representation or formatting may differ (for example, address elements may have been expanded or abbreviated, or capitalisation changes may have been made).
00000080 The amount of input lines specified during configuration does not match the number of lines found in the input file. This Information Bit does not affect the confidence level.
00000001 An unambiguous match has been found, but stricter checks have resulted in the confidence level being reduced to, at best, intermediate.
00000002 Clean has found a premises level partial address match.
00000004 Clean has found a street level partial address match.
00000008 Clean has found a place level partial address match.

Country information bits

Country Information Bits are used to communicate detailed changes to your address information.

Country Information Bits are added together to make up a hexadecimal code. The example above (which relates to USA data) is a combination of 1000000 (ZIP+4 has been assigned) and 08000000 (Address converted using LACS).

Asia-Pacific

Australia

Information BitDescription
10000000 An exact street level match is not possible as more than one non-exact match is possible by changing either a supplied street element or the supplied locality. If this information bit is set, no match is returned.
20000000 Multiple street type(s) or invalid street type(s) are supplied in the input address, and there is more than one match with the equivalent match quality. If this information bit is set, match confidence is reduced.
40000000 Multiple PO Box types were supplied in the input address, or the changes required to obtain a match makes the input postal delivery type invalid. If this information bit is set, match confidence is reduced.
80000000 A bordering locality match is prohibited because a match is already available in the locality that was entered, and can be returned by changing the street type or street type suffix
01000000

No additional valid secondary information has been supplied in the input address given a real or phantom primary point reference address match.

02000000 A match has been made to a real primary point, a holding premises which is a valid delivery point in itself.
04000000

A match has been made to a phantom primary point. These are holding premises which cannot be a valid delivery point without valid additional secondary information.
If the address is cleaned in the AMAS certified mode, match confidence will be reduced to intermediate if information bit 01000000 is also set.

00100000 The supplied Customer Barcode Info field is blank.
00200000

Invalid characters are present in the supplied Customer Barcode Info field. The valid characters are letters, numbers, spaces and hashes.

00400000

The 52 digit extended barcode (AUSBAR.Ext52) can convert a maximum of 5 Customer Barcode Info characters. If your Customer Barcode Info contains more than 5 characters, this information bit is returned and the field is treated as blank when generating the barcode.

00800000

The 67 digit extended barcode (AUSBAR.Ext67) can convert a maximum of 10 Customer Barcode Info characters. If your Customer Barcode Info contains more than 10 characters, this information bit is returned and the field is treated as blank when generating the barcode.

00010000

The building number has been amended. For example, a single number in the input address has been matched to a range containing that number.

00020000 There was an error in the building name.
00040000

Floor/Level information has been added or amended.

00080000 Flat/Unit information has been added or amended.
00001000 There was an error in the street name.
00002000 The street type has been added or changed.
00004000 The street type suffix has been added or changed.
00008000 A street alternate form has been matched and may be retained in the output address (where the ‘Street alias’ output item has been fixed during configuration).
00000100 There was an error in the locality information supplied in the input address.
00000200 There was an error in the state information supplied in the input address.
00000400 The flat/unit number or the sub-premise number that was entered did match that in the data, but the type/descriptor did not match. In this case, the type or descriptor entered by the user will be retained in the output address.
00000800 A valid bordering locality and postcode combination has been matched.
00000010 Street level (DID) address matched.
00000020 Locality level (DID) address matched.

Australia G-NAF

Information BitDescription
10000000 A street alias has been matched and may be retained in the output address if the street alias output item has been fixed during configuration.
20000000 A locality alias has been matched and may be retained in the output address if the locality alias output item has been fixed during configuration.
40000000 A bordering locality has been matched and may be retained in the output address.
01000000

A match has been made to premises-level, specifically building number, only. No sub-premises item has been matched.

02000000 No additional valid secondary information has been supplied in the input address. A building number has been supplied and matched.
04000000 A building number and valid secondary information have been supplied in the input address but neither matched. The unmatched secondary information may be retained in the output address.
00100000 A valid PO Box type has been supplied in the input address.

New Zealand

Information BitDescription
10000000 Unique match - matches to a unique delivery address.
20000000 Base Address match - matches to a street number.
40000000 Invalid match - does not match to a delivery address.
01000000

Sub-premise information added.

02000000 Street Type difference in matched address.
04000000 Street Name difference in matched address.
08000000 Street Direction difference in matched address.
00200000

Rural delivery difference in matched address.

00400000

An invalid match caused by matching a suburb alias. This bit will only be set if other elements were valid.
Records with this information bit will be excluded from the SOA report, if you requested one.

00800000

Rural address match with missing or unmatched premise info.
Records with this information bit will be excluded from the SOA report, if you requested one.

00010000

This bit will be set for Poste Restante addresses.
Records with this information bit will be excluded from the SOA report, if you requested one.

00020000

This bit will be set for Private Bag addresses.
Records with this information bit will be excluded from the SOA report, if you requested one.

00040000

Lobby added or corrected in matched address.

00080000 Suburb added or corrected in matched address.
00001000 City added or corrected in matched address.
00002000 A valid suburb alias has been matched and may be retained in the output address if the suburb alias output item has been fixed during configuration.
00004000 A valid city alias has been matched and may be retained in the outputp address if the city alias output item has been fixed during configuration.
00000100 Unambiguous match to an address with ‘deleted’ status with no alterations to any of the PAF address elements.

Singapore

Information BitDescription
10000000 Floor/unit numbers were supplied, but not matched in the data. The supplied floor/unit numbers have been returned as part of the address.
20000000 Additional unit information was supplied, but is not available in the dataset. The supplied additional unit information has been returned as part of the address.

North America

Canada

Information BitDescription
10000000 Premises number optimized, changed or inserted.
20000000 Route number optimized, changed or inserted.
40000000 Extraneous data optimized, changed, inserted or removed.
80000000 Street suffix optimized, changed, inserted or removed.
01000000 Station name optimized, changed, inserted or removed.
02000000 Station type optimized, changed, inserted or removed.
04000000 Station qualifier optimized, changed, inserted or removed.
08000000 Province optimized, changed, inserted or removed.
00100000 Street type optimized, changed, inserted or removed.
00200000 Street direction optimized, changed, inserted or removed.
00400000 Community optimized, changed, inserted or removed.
00800000 Street name optimized, changed, inserted or removed.
00010000 Apartment keyword optimized, changed, inserted or removed.
00020000 Route/Box keyword optimized, changed, inserted or removed.
00040000 Foreign record keyword optimized, changed, inserted or removed. 
00080000 Apartment number optimized, changed, inserted or removed.
00001000 Box number optimized, changed, inserted or removed.
00002000 Street number outside valid range.
00004000 Route Number outside valid range.
00008000 Invalid '#' symbol in address.
00000100 Valid Postal CodeOM.
00000200 Postal CodeOM changed from Rural to Urban.
00000400 Postal CodeOM corrected.
00000800 Local Delivery Unit (LDU) changed.
00000010 Forward Sortation Area (FSA) changed.
00000020 Postal CodeOM inserted.
00000040 Postal CodeOM changed.
00000080 A better Postal CodeOM exists.
00000001 Address considered Valid for SERP (no changes required to input).
00000002 Address considered Correctable for SERP (input has been corrected and a unique match supplied).
00000004 Address considered Non-Correctable for SERP (input could not be corrected or is too ambiguous to supply a unique match).

United States

Information BitDescription
10000000 ZIP+4 has been assigned.
20000000 DPBC has been assigned.
40000000 5-digit ZIP has been assigned.
80000000 Address is a High Rise Default.
01000000 Address is a High Rise Exact.
02000000 Address is a Rural Route Default.
04000000 Address is a Rural Route Exact.
08000000 Address converted using LACS.
00100000 USPS footnote A: 5-digit ZIP Code has been corrected.
00200000 USPS footnote B: City/State spelling has been corrected.
00400000 USPS footnote C: City/State/ZIP are invalid.
00800000 USPS footnote D: No ZIP+4 has been assigned.
00010000 USPS footnote E: ZIP Code has been assigned for multiple response.
00020000 USPS footnote F: Address not found in the dataset with City/State/ZIP provided.
00040000 USPS footnote G: Part of the firm was moved to address.
00080000 USPS footnote H: Secondary number was missing for this address.
00001000 USPS footnote I: Insufficient/incorrect address data supplied.
00002000 USPS footnote J: PO Box address used for dual address.
00004000 USPS footnote K: Non-PO Box address used for dual address.
00008000 USPS footnote L: Delivery address component has been changed.
00000100 USPS footnote M: Street name has been changed.
00000200 USPS footnote N: Delivery address has been standardised.
00000400 USPS footnote P: Delivery address is known by a preferred name.
00000800 USPS footnote R: Address is not in current data, but will be added in the future.
00000010 USPS footnote S: Secondary number does not match.
00000020 USPS footnote T: Address has magnet street syndrome (multiple).
00000040 USPS footnote U: City or PO name supplied was not an official last line name.
00000080 USPS footnote V: City or state could not be verified as corresponding to the ZIP code.
00000001 USPS footnote W: Address was identified as a small town default.
00000002 USPS footnote X: Address has a unique ZIP code default.
00000004 USPS footnote Z: Match made using ZIPMOVE data.
00000008 USPS footnote Q: Match has been made to a unique ZIP.

Europe

France

Information BitDescription
10000000 The address was deemed to be correct as supplied. All address elements were supplied on the correct lines and in the correct format.
20000000 The address was matched with a high degree of confidence, but some corrections were made. For example, spelling or formatting may have been corrected, or missing address elements may have been added.
40000000 A match was found, but Clean cannot be certain that the returned address is the correct one. For example, the returned address may be very different from the input, important address elements may have been changed, or other equally good matches may exist in the data. The match has been downgraded to intermediate confidence, and the user should check the returned address manually.
80000000 As well as the returned address, Clean found one or more alternative addresses of similar quality. For example, the supplied street does not exist but there are two very similar streets to choose from. When this situation arises, the information bit 4000000 is also set.
01000000 The returned address is in a format that conforms to the AFNOR standard. This specifies which address line should be used for each address element, the maximum length of each line, and the abbreviations that should be used.
00001000 A secondary street name was supplied but was not matched in the data. This has been returned as part of the address.
00000100 A premises number was supplied for the secondary street but was not matched in the data. This has been returned as part of the address.
00000200 A premises suffix was supplied for the secondary street but was not matched in the data. This has been returned as part of the address.
00000010 A primary street name was supplied but was not matched in the data. This has been returned as part of the address.
00000020 A locality name was supplied but was not matched in the data. This has been returned as part of the address.
00000040 A PO Box number was supplied for the primary street but was not matched in the data. This has been returned as part of the address.
00000080 An organisation name was supplied for the primary street but was not matched in the data. This has been returned as part of the address.
00000001 A premises number was supplied for the primary street but was not matched in the data. This has been returned as part of the address.
00000002 A premises suffix was supplied for the primary street but was not matched in the data. This has been returned as part of the address.

Ireland

Information BitDescription
10000000 English Primary Locality added that was not supplied in the input address
20000000 Gaelic Primary Locality added that was not supplied in the input address
40000000 English Secondary Locality added that was not supplied in the input address
80000000 Gaelic Secondary Locality added that was not supplied in the input address
01000000 Street retained from the input address that is not in the data
02000000 Street added that was not supplied in the input address
00100000 Match to bordering locality
00200000 Match to bordering Dublin district number
00400000 Wrong Dublin district number supplied
00800000 Match to bordering county
00020000 Posttown added
00001000 Gaelic Primary Thoroughfare available
00002000 Gaelic Secondary Thoroughfare available
00004000 Gaelic Primary Locality available
00008000 Gaelic Secondary Locality available
00000100 English Posttown has been removed
00000200 Gaelic Posttown has been removed
00000400 English Resident Preferred Posttown has been removed
00000800 Gaelic Resident Preferred Posttown has been removed
00000010 Non-trivial change applied as a result of referencing An Post data

United Kingdom

Information BitDescription
10000000 Postcode has been recoded.
20000000 Multiple recodes exist for supplied postcode.
01000000 Town added or altered.
02000000 County added or altered.
04000000 PNR county form present for matched address.
00100000 Dependent locality added or altered.
00200000 Double dependent locality added or altered.
00400000 Postally non-required locality alias is retainable in the output address.
00010000 Thoroughfare name difference.
00020000 Thoroughfare descriptor added or changed.
00040000 Dependent thoroughfare name difference.
00080000 Dependent thoroughfare descriptor added or changed.
00001000 Building number corrected (for example, a single premises number corrected to a range).
00002000 Building name amended.
00004000 Sub-building number corrected (for example, a single premises number corrected to a range).
00008000 Sub-building name amended.
00000100 Organisation name altered.
00000200 Organisation name matched to reference initials.
00000400 Organisation department name added or changed.

Country

A Country identifier is appended to all match codes, and indicates the country which Clean cleaned (or attempted to clean) the address against.

Copyright ©, 2014-2017. All rights reserved.