Clean Web Service version 1 is synchronous so it therefore responds to just a single request, ProcessRecords.
Clean Web Service version 2 is asynchonous so it therefore responds to two different requests; SubmitRecords and GetResults.
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:
Section | Supported Tags | Parameters | Description |
---|---|---|---|
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 | KeyValue | Contains an array of settings presented as Key / Value pairs. |
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
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
This section is a wrapper used to provide Clean Web Service with an array of records for processing.
<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>
Each record is provided within a Record tag. Within this, the Fields block contains an array ofstrings , which each hold a different kind of field. In the example above, the Record contains the followingstrings :
<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 perstring ).
<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.
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.
This section identifies the workflow which should be applied to the address records sent in a request.
<ns:workflow>CleanEnrich</ns:workflow>
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.
The following workflows are available:
This section is a wrapper used to contain an array of settings particular to the workflow you have specified.
<ns:settings>
<ns:namedvalue>
<ns:key>UserLabel</ns:key>
<ns:value>CleanTest</ns:value>
</ns:namedvalue>
...
</ns:settings>
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.
The settings available for each workflow are as follows:
Key | Value |
---|---|
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._
Key | Value |
---|---|
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. |
Key | Value |
---|---|
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. |
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).