API Versions

This documentation relates to Version 3, the current version of the greenID API. Version 3 became available to customers as of 03 Apr 2017.

CurrentStatusV3

The CurrentStatusV3 object is the sole return type of all the web methods in the API. It is intended to provide information about what has just happened, as well as giving an overview of the person’s current verification status, and the list of data sources that will help the person become fully verified. Always presenting this information helps to reduce the chattiness between greenID and the customer application.

Name	Type	Description
`sourceList`	`SourceListV3`	This member contains a list of `SourceV3` objects, each of which corresponds to a data source that is available to the person for the purpose of becoming fully verified. The `setFields` web method expects one of these names as the `sourceId` input parameter.
`verificationResult`	`VerificationResultV3`	This member contains all of the verification information currently available for a person. It is a complete record of all checks that have been performed, their results, and an indicator of the person’s overall verification status.
`sourceFields`	`SourceFieldsV3`	This member contains a list of fields that are required for a particular data source. This includes the field’s name, type and other pertinent information for displaying and collecting a value for the field.
`checkResult`	`LastCheckResultV3`	This member indicates the outcome of a check against a data source that was performed during a call to the `setFields` web method. This member also indicates whether the check is still in progress.
`verificationToken`	`String`	This field is for future features in the API, and can be ignored for now.

LastCheckResultV3

The LastCheckResultV3 object is intended to give a snapshot of the status of a check that has been performed during a call to the setFields web method.

Name	Type	Description
`stillWorking`	`boolean`	This member indicates whether the check is still in progress. This feature is still under development; currently the value is always `false`.
`state`	`String`	This member gives the current state of the check. Refer to the Reference Table for Individual Source States for valid values.

SourceListV3

Name	Type	Description
`sources`	`List<SourceV3>`	Simply a list of `SourceV3` objects.

SourceV3

Name	Type	Description
`state`	`String`	This member reflects the current state of the source. The valid values are the same as the state member of the `CheckResultV3` object. If a source has not been used, then this member will be “EMPTY”.
`passed`	`boolean`	This member indicates whether this source has been passed, i.e. the check is in one of the verified states.
`name`	`String`	This member is the name of the data source. This name is expected to be used to refer to this data source in calls to the `setFields` web method.
`available`	`boolean`	This member indicates whether this data source is currently available; sometimes a particular data source may not be available.
`notRequired`	`boolean`	This member indicates whether this data source can help a person become fully verified. If the value is `true`, then there is no point using this data source because it cannot help the person become fully verified.
`oneSourceLeft`	`boolean`	This member indicates whether completing this data source will make a person fully verified. This member is very valuable because it indicates which sources should be attempted first, thereby shortening the verification process.
`order`	`int`	The order in which the source would be displayed if it were being displayed by greenID. Sources that are more likely to result in the person becoming fully verified are at the top of the list, i.e. their “order” number is lower.
`attributes`	`List<NameValuePair>`	This member contains a list of HTML attributes that should be applied to any HTML input collecting input from a person. For example, the HTML attribute `“class=’required’”` would be represented by a `NameValuePair` with `name=”class”` and `value=”required”`.

SourceFieldsV3

Name	Type	Description
`fieldList`	`FieldListV3`	This member contains a list of fields that are required for a particular data source. The members of list represent HTML fields for collecting input from the person.
`rawData`	`String`	This member contains an HTML fragment that, if displayed, will present HTML fields for collecting data from a person in order to perform a check against a data source. Some customer may prefer this approach rather than generating their own HTML from the data contained in the `fieldList` member.

FieldListV3

Name	Type	Description
`sourceField`	`List<FieldV3>`	This member simply contains a list of `FieldV3` objects.

FieldV3

Name	Type	Description
`type`	`String`	The type of HTML input that is required (at least strongly suggested) for collecting the data for this field from the person. For example, a value of “text” would indicate a simple HTML text input is appropriate.
`name`	`String`	The name of the HTML input that would collect data for this field from the person. The name also indicates what the data field is, for example, the value “aec_givenname” indicates the field holds the given name for the AEC data source.
`value`	`String`	This member contains any pre-existing value for the HTML field. For example, the `FieldV3` with the name `aec_givenname` will be pre-populated with the person’s given name (derived from the person’s master record established during the call to the `RegisterVerification` web method) the first time the `getFields` method is called with the sourceId `aec`.
`label`	`String`	This member contains label. Please refer to the section on Labels.
`selectItem`	`List<NameValuePair>`	This member contains a list of item names and values for a select item `FieldV3`.
`attribute`	`List<=NameValuePair>`	This member contains a list of the names and values of any HTML attributes that this Field has. For example, the attribute `class=”required”` would be represented by a `NameValuePair` with `name=”class”` and `value=”required”`.

InputFields

Name	Type	Description
`input`	`List<NameValuePair>`	This member contains a list of names and values that correspond to input parameters to the `setFields` web method. The names are expected to be those that have previously been returned from the `getFields` method for a particular data source. For example, a visa number will be represented by a `NameValuePair` with `name=”visa_number”` and `value=”11111111”`.

DateOfBirth

This type is a convenience type for holding a partial date, especially useful for representing dates of birth. This type holds just the date part, and does not contain any reference to a time component or timezone; this avoids potential issues with date of birth timestamps arising from different timezones.

Name	Type	Description
`day`	`int`	The day component of a date of birth.
`month`	`int`	The month component of a date of birth.
`year`	`int`	The full year component of a date of birth, for example 1975, i.e. not 75.

RegistrationDetailsV3

Name	Type	Description	Contract
`currentResidentialAddress`	`Address`	The person's current residential address.
`dateCreated`	`String`	The timestamp of when this verification attempt was created. The string will be formatted in the ISO 8601 format. The pattern used to generate this string in Java is `yyyy-MM-dd'T'HH:mm:ss.SSSZ`.
`dob`	`DateOfBirth`	The person's date of birth.
`email`	`String`	The person's email address.	May be null. Must be a valid email address following the Standard Hibernate validation and checking Top Level Domain (TLD) is valid. See https://data.iana.org/TLD/tlds-alpha-by-domain.txt
`extraData`	`List<NameValuePair>`	Any extra data elements that were supplied with the original registration. Identifier such as document numbers will not be present in the list, even if they were supplied at registration time.	Zero or more elements.
`homePhone`	`String`		If present, must be 10 digits only.
`mobilePhone`	`String`		If present, must be 10 digits only.
`name`	`Name`	The person's name.
`previousResidentialAddress`	`Address`	The person's previous residential address.
`workPhone`	`String`		If present, must be 10 digits only.

Address

The Address object is intended to serve as a container for address information for countries with a variety of different address schemes and formats. The fields that are present or required will depend on the country that is specified. Similarly, fields may have different validation rules depending on the country, for example, the field "postcode" must be a four digit string for an Australian address, but it must be a five digit string for a US address. For requirements for individual countries, please refer to Address Handling or contact greenID.

Name	Type	Description	Contract
`alley`	`String`
`amalgamatedMunicipality`	`String`
`area`	`String`
`avenue`	`String`
`block`	`String`
`canton`	`String`
`chome`	`String`
`city`	`String`
`country`	`String`	The country code. This must be the ISO 3166 country code. The country code can be given in either the alpha-2, alpha-3 or numeric format.	Please refer to https://www.iso.org/obp/ui/#search for a full (and up to date) list of ISO 3166 country codes.
`county`	`String`
`deliveryNumber`	`String`
`department`	`String`
`direction`	`String`
`dispatchingInformation`	`String`
`district`	`String`
`divisionFive`	`String`
`divisionFour`	`String`
`divisionOne`	`String`
`divisionThree`	`String`
`divisionTwo`	`String`
`flatNumber`	`String`
`level`	`String`
`locality`	`String`
`location`	`String`
`mailCentre`	`String`
`municipality`	`String`
`neighbourhood`	`String`
`organisation`	`String`
`parish`	`String`
`personName`	`String`
`poBox`	`String`
`postcode`	`String`
`prefecture`	`String`
`propertyName`	`String`
`province`	`String`
`quarter`	`String`
`region`	`String`
`ruralArea`	`String`
`ruralLocality`	`String`
`sector`	`String`
`sectorNumber`	`String`
`state`	`String`
`streetName`	`String`
`streetNumber`	`String`
`streetType`	`String`
`subdistrict`	`String`
`subregion`	`String`
`suburb`	`String`
`town`	`String`
`townCity`	`String`
`township`	`String`
`urbanLocality`	`String`
`village`	`String`

Name

The Name complex type has the following structure:

Member	Type	Required?	Description	Contract
`honorific`	`String`	No	The honorific component of a person’s name, e.g., “Mr”, “Miss”, etc.	Max 255 characters.
`givenName`	`String`	Yes	A person’s given name.	Cannot be null. Cannot be the empty string. Max 255 characters.
`middleNames`	`String`	No	A person’s middle names. Note that there can be multiple names.	Max 255 characters.
`surname`	`String`	Yes	A person’s surname or last name.	Cannot be null. Cannot be the empty string. Max 255 characters.

VerificationResultV3

The VerificationResultV3 type describes the person’s verification results to date. This is always returned so that the caller always has the latest results for that person.

Name	Type	Description
`overallVerificationStatus`	`String`	This member indicates the outcome of the entire verification process. Refer to the Reference Table for Overall Outcome States for values.
`ruleId`	`String`	The identifier for the rule that was used to determine the verification outcome.
`mode`	`String`	This member indicates the verification mode that was used. The mode is `null`, except in the following cases: “POSTOFFICE” – the person was verified by completing a Post Office form and visiting a branch of Australia Post, where their identity documents were manually inspected. “ASSISTED” – the person was verified by an administrative user. “EXTERNAL” – the person was verified outside of greenID, and the results have been loaded in to greenID.
`dateVerified`	`String`	The date this person became verified (null if they have not yet been verified).
`individualResults`	`List<CheckResultV3>`	This member holds a list of results for the individual checks that have been performed to date.
`verificationID`	`String`	The unique identifier for this verification attempt.

CheckResultV3

The CheckResultV3 type contains all the details of a check against a particular data source.

Name	Type	Description
`name`	`String`	The name of the check. For example, if a check against the Electoral Roll was attempted, then the name would be “AEC”. As each customer will accept a different set of checks, customers should refer to their individual rules document for the list of names that they can expect. Refer to Data Source Reference for a list of data source names.
`state`	`String`	The state of the individual check. For a list of possible states, please see the Reference Table of Individual Source States.
`method`	`String`	The method via which the check was carried out. This is an enumerated type, for a list of possible values, please see the Reference Table of Method Names.
`mode`	`String`	The verification mode used for this specific check. This shows HOW the check was made. Please see the Reference Table of possible modes. This can be `null` which indicates that no mode was used.
`dateVerified`	`String`	The date that this particular check became verified (or null if the check is not verified). The string will be formatted in the ISO 8601 format. The pattern used to generate this string in Java is `yyyy-MM-dd'T'HH:mm:ss.SSSZ`.
`fieldResult`	`List<FieldResultV3>`	Only the fields that were successfully checked, or were changed, are returned. Any field that was not checked is not returned. Note that this may mean the list is empty.
`postOfficeData`	`PostOfficeDataV3`	If and only if the name of the `CheckResultV3` is “PostOffice” then this member will be present. Otherwise it will be null. This represents the raw data retrieved from Australia Post.
`extraData`	`List<NameValuePair>`	Any extra data associated with this check. As an example, an OCR Document may have a key value pair named "origin" whose value indicates the channel that the OCR Document was completed on. Possible values include: greenID Mobile V1, greenID Mobile V2 and greenID Web.
`individualResult`	`List<CheckResultV3>`	A list of nested `CheckResultV3` objects, which are used for representing combination sources. A combination source has five nested elements, each of which will have a corresponding `CheckResultV3` object in this list. Those five elements are: document authenticity, data extraction, data source, facial recognition match, and comparison to the master record. These elements are discussed in detail below.
`documentType`	`String`	The category the document belongs to. Common values are: DRIVERS_LICENCE PASSPORT NATIONAL_ID_CARD Extra document types will be used as necessary, and if they apply to you, greenID will provide details about the appropriate values.
`documentRegion`	`String`	The region or country the document is associated with. The ISO alpha2 country designation is used.
`documentSubRegion`	`String`	Some document depend on the state or region within the country that issued them. For example, in Australia, each state issues their own driver's licences, so the state must be included to accurately identify the ID document.
`faceMatchScore`	`String`	A string representation of a number that reflects the confidence score that the selfie matches the image extracted from the ID document. The range of valid numbers is 0 to 100.

Combination sources, as the name suggests, combine multiple things into a single source. Combination sources are used when the greenID Mobile SDK captures an identity document for verification. A combination source will always have the following three components present:

document authenticity - this component represents the outcome of the automated authenticity and integrity checks that are performed on the image of the document to ensure it is an authentic document, and has not been subject to digital tampering.
data extraction - this component represents the data that was automatically extracted from the card, and how it relates to the data that the person confirmed.
document registration match - this component represents the comparison between the details that the person confirmed and the master record.

An example of an XML snippet for the document authenticity component is below, showing an Australian ACT driver's licence that was deemed authentic, indicated by the VERIFIED state:

<individualResult>
   <documentRegion>AU</documentRegion>
   <documentSubRegion>ACT</documentSubRegion>
   <documentType>DRIVERS_LICENCE</documentType>
   <method>interactive</method>
   <name>Document Authenticity</name>
   <state>VERIFIED</state>
</individualResult>

Components initially in a pending state have the option of being reviewed; during this process the administrator is required to give a comment on the review. These comments can be returned in the API if configured. The XML captures the comment, the date and time it was made, and the email address of the administrator making the change. An example of the XML that was verified by an administrator is seen below:

<individualResult>
    <dateVerified>2018-12-04T10:31:28.440+1000</dateVerified>
    <fieldResult>
        <data>Ive uploaded a picture of a big beer can</data>
        <extraData>
            <name>Date</name>
            <value>2018-12-04 10:31:28.44</value>
        </extraData>
        <extraData>
            <name>AdminEmail</name>
            <value>admin@edentiti.com</value>
        </extraData>
        <name>AdminComment</name>
    </fieldResult>
    <method>interactive</method>
    <name>Telephone Bill</name>
    <state>VERIFIED_ADMIN</state>
</individualResult>

When a document image is captured by the greenID Mobile SDK, the person has the chance to review the data that was automatically extracted from the image to correct any errors that the OCR process might have made. The results of the OCR process and the so-called "confirmed data" are compared to see how well the OCR process performed, and how many changes the person had to make. If no changes were made, then the data extraction component will be in the VERIFIED state, as in the example below:

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>VERIFIED</state>
</individualResult>

The comparison between the data that was read during OCR and the confirmed data is subject to the greenID controlled changes process. If the changed made by the person are automatically accepted by the controlled changes process, then the data extraction component can have the VERIFIED_WITH_CHANGES state. If the changes are too large, then the data extraction component can be in the PENDING state, as in the example below where the person changed their surname:

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <extractedValue>Smith</extractedValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>PENDING</state>
</individualResult>

As with regular data sources in greenID, a comparison is made between the data used to check the data source and the master record. Combination sources are the same in this regard. When a person confirms the details extracted from their ID document, with or without changes, the "confirmed data" is compared to the master record, and the changes are subject to the greenID controlled changes process. (The confirmed data may also be used with an external data source, depending on customer account configuration.) The document registration match component reflects this comparison. The XML snippet below shows a document registration match component where no data was changed by the person during the confirmation step:

<individualResult>
   <dateVerified>2017-01-19T11:37:11.796+0000</dateVerified>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>VERIFIED</state>
</individualResult>

Of course, the person may make changes during the confirmation step, and if these changes are too large, the document registration match component can be in the PENDING state, as in the example below where the person changed their surname:

<individualResult>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <masterRecordValue>Smith</masterRecordValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>PENDING</state>
</individualResult>

There are two more components to a combination source that may appear, depending on customer account configuration:

data source - an external data source that can verify the data read from the document, for example, the government department that issues passports.
face comparison - a comparison between the image of a person extracted from an identity document, such as a passport, and a live selfie of the person captured by the greenID Mobile SDK.

If the data source element is present, then the name of the data source and state of the check will be present, for example, the snippet below shows the data source associated with Australian passports was checked and passed:

<individualResult>
   <method>interactive</method>
   <name>PassportDVS</name>
   <state>VERIFIED</state>
</individualResult>

The face comparison component will only be present if face comparisons are configured on the customer's account. If present, the face match score and the state of the face comparison will be present, for example:

<individualResult>
   <faceMatchScore>55</faceMatchScore>
   <method>interactive</method>
   <name>Face Comparison</name>
   <state>VERIFIED</state>
</individualResult>

FieldResultV3

Name	Type	Description
`addressType`	`String`	Either `currentAddress` or `previousAddress`, depending on whether the address was nominated as their current or previous residential address at registration time. This field will only be present for fields that are address related fields.
`name`	`String`	The name of the field. The possible name will depend on the source used. Again which sources used will depend on the individual customer setup, and new sources, with potentially new fields are constantly being added. For a list of possible field names for each source, please refer to the Data Source Reference tables.
`status`	`String`	This member indicates the status of the field. Refer to the Reference Table for Field Status for possible values.
`value`	`String`	This member contains the original data that was supplied the time of registration, or the “master record”. In the case of a status of ADDITION (see the Reference Table of Field Status) then this will hold the added data.
`extraData`	`List<NameValuePair>`	Any extra data associated with this check.
`format`	`String`	This member indicates the format of the data in this field. This field will only be present for fields that are encrypted, in which case it will have the value `PGPEncrypted`.
`masterRecordValue`	`String`	This member is reserved for use with combination sources. It's use is discussed below.
`changedValue`	`String`	This member will contain changed values. That is, if a value was changed in order to become verified, then this member will contain the value that the data was changed to, and subsequently verified.
`extractedValue`	`String`	This member is reserved for use with combination sources. It's use is discussed below.

Regular data sources will have a list of FieldResultV3 elements that have the following elements populated:

name
status
value - if the value of the field was not changed for use with this data source.
changedValue - if the value of the field was changed for use with this data source, then the value field will not be present. Instead, the changedValue field will be present, and will contain the value that was used with this data source.
masterRecordValue - if the value of the field was changed for use with this data source, then the masterRecordValue is included to explicitly show the change that was made. The masterRecordValue field shows the value of the field from the master record, i.e. the value that was used when registering this verification attempt with greenID.

To illustrate the use of the value, changedValue and masterRecordValue elements, consider an example where the DoB field was not changed with respect to the master record. The DoB field would be represented by the XML snippet below:

<fieldResult>
   <name>dob</name>
   <status>CONFIRMED</status>
   <value>1976-04-26</value>
</fieldResult>

Now consider that the DoB was changed from 1/1/1980 on the master record to 1/4/1976 when using the data source, then the following XML snippet would be present:

<fieldResult>
   <changedValue>1976-04-01</changedValue>
   <masterRecordValue>1980-01-01</masterRecordValue>
   <name>dob</name>
   <status>CHANGED</status>
</fieldResult>

This scheme makes explicit every change that was made between the data used for the data source, and the master record.

The scheme becomes a little more complicated when combination sources are used. For a discussion of when the various elements of a combination source, please refer to the previous section about the CheckResultV3 type. The main thing to note in this section is which elements of the FieldResultV3 type are present in the different components comprising a combination source.

In the data extraction component of a combination source, the value field will be present if the status field has the value CONFIRMED, as in the example below.

<fieldResult>
   <name>surname</name>
   <status>CONFIRMED</status>
   <value>Smith</value>
</fieldResult>

If the value has been changed, and the status field has the value CHANGED, then the changedValue element will hold the value that the person altered, and the extractedValue element will contain the value that was automatically read from the ID document. For example, the XML below shows the FieldResultV3 element when a person has changed the value that was read from the card from "Smith" to the value "Jones":

<fieldResult>
   <changedValue>Jones</changedValue>
   <extractedValue>Smith</extractedValue>
   <name>surname</name>
   <status>CHANGED</status>
</fieldResult>

In the document registration match component of a combination source, the value field will be present if the status field has the value CONFIRMED, as in the example below:

 <fieldResult>
    <name>surname</name>
    <status>CONFIRMED</status>
    <value>Smith</value>
 </fieldResult>

If the value has been changed, and the status field has the value CHANGED, then the changedValue element will hold the value value that the person altered, and the masterRecordValue element will contain the value that is associated with the master record. For example, the XML below shows the FieldResultV3 element when a person has a master record where their surname is recorded as "Smith", and the combination source has the surname "Jones" (the value could be different because the person used an identity document with the surname "Jones" on it, or changed the value to "Jones" when asked to confirm the data automatically read from the card):

 <fieldResult>
    <changedValue>Jones</changedValue>
    <masterRecordValue>Smith</masterRecordValue>
    <name>surname</name>
    <status>CHANGED</status>
 </fieldResult>

PostOfficeDataV3

The PostOfficeDataV3 complex type and the following members are for the most part exact representations of the fields found in an Australia Post contract. The reader should be aware of the individual Australia Post contract they will be using to ensure that they can match up the fields. These fields are retrieved from a flat file and stored in Strings with no interpretation of the meanings of the fields. Not all implementations of an Australia Post contract will have all the fields detailed below.

Member	Type	Description	Contract
`customerId`	`String`	This parameter is GreenID's identifier for the client application. The value is supplied by GreenID.	Not null. Max 255 chars.
`documents`	`String`	Human readable string that is a comma separated list of all the names of the documents used to verify this user.	Not null.
`header`	`DetailRecordHeader`	Representation of the header of the flat file received from Australia Post.	Not null.
`poFileName`	`String`	The name of the actual file read from Australia Post.	Not null. Max 255 chars.
`records`	`DocumentRecord[]`	List of individual representations of the documents used to verify this User	Not null.

DetailRecordHeader

The complex type DetailRecordHeader has the structure described below:

Member	Type	Description	Contract
`amount`	`String`	Unsigned amount in cents.	Max 255 chars.
`channelId`	`String`	0 = default	Max 255 chars.
`date`	`String`	ddmmyy (NOTE: system generated date with no slashes)	Max 255 chars.
`dateOfBirth`	`String`	ddmmyyyy represents the date of birth on the form that was checked.	Max 255 chars.
`filler`	`String`	Often there will be filler, it serves no purpose and should be ignored.	Max 255 chars.
`formVersion`	`String`	A-Z	Max 255 chars.
`givenName`	`String`	16 characters of the given name that was on the form that was checked.	Max 255 chars.
`id`	`Long`	Extra identifier that identifies this record. Not set by Australia Post.
`idWizardRefNo`	`String`		Max 255 chars.
`paymentMethod`	`String`	'00' = Cash/EFTPOS/Direct Debit, '01'-'09' = number of Cheques, '11' = VISA, '12 = MasterCard. Note: This may differ per contract, but in general the above applies.	Max 255 chars.
`phoneNo`	`String`	Phone number as entered on the form that was checked.	Max 255 chars.
`postOfficeName`	`String`	Presumably the name of the Post Office the form was checked at.	Max 255 chars.
`recordNo`	`String`	Seems to be fixed as ‘1’.	Max 255 chars.
`recordType`	`String`	Seems to be fixed as ‘5’.	Max 255 chars.
`referenceNo`	`String`	The reference number used to identify this user. Most often this will be the userId. It must be 16 characters or less.	Max 255 chars.
`surname`	`String`	20 characters of the surname that was on the form that was checked.	Max 255 chars.
`totalNumberOfIdDocument`	`String`	Number of documents used to verify this user.	Max 255 chars.
`typeCode`	`String`		Max 255 chars.
`uniqueReferenceNumber`	`String`	wwwwwwttnnnnn, first 6 digits are AP Work Centre Code.	Max 255 chars.

DocumentRecord

The DocumentRecord complex type has the structure described below:

Member	Type	Description	Contract
`amount`	`String`	Always zero.	Max 255 chars.
`comments`	`String`		Max 255 chars.
`countryOfIssue`	`String`	Name of country from the document if applicable.	Max 255 chars.
`dateOfBirthMatchesaForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`documentExpiryDate`	`String`	dd/mm/yyyy; spaces if not applicable NOTE: (manually entered date with slashes)	Max 255 chars.
`documentName`	`String`	This is an automatic lookup to convert the idDocumentType member into a human readable document name.	Max 255 chars.
`documentNumber`	`String`	Alphanumeric, e.g., passport number.	Max 255 chars.
`filler`	`String`	Often there will be filler, it serves no purpose and should be ignored.	Max 255 chars.
`id`	`Long`	Extra identifier that identifies this record. Not set by Australia Post.
`idDocumentType`	`String`	Code number representing the document type. The lookup for the name is done automatically and stored in the documentName member.	Max 255 chars.
`idWizardRefNo`	`String`		Max 255 chars.
`issuedBy`	`String`	This may be present instead of country of Issue, stateOrTerritoryOfIssue, utilityAccountIssuer and utilityAccountType. It may selectively hold this information in a less rigid format.	Max 255 chars.
`issueDate`	`String`	dd/mm/yyyy; spaces if not applicable NOTE: (manually entered date with slashes) May not be present.	Max 255 chars.
`nameMatchesForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`photoMatch`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`recordNo`	`String`		Max 255 chars.
`recordType`	`String`		Max 255 chars.
`referenceNo`	`String`		Max 255 chars.
`residentialAddressMatchesForm`	`String`	Y = Yes, X = not applicable	Max 255 chars.
`stateOrTerritoryOfIssue`	`String`	ACT, QLD, NSW, NT, SA, TAS, VIC or WA.	Max 255 chars.
`utilityAccountIssuer`	`String`	If specifically a utility, then the name.	Max 255 chars.
`utilityAccountType`	`String`	01 = electricity, 02 = gas, 03 = water, 04 = telephone	Max 255 chars.

NameValuePair

The NameValuePair complex type has the following structure:

Member

Type

Required?

Description

Contract

name

String

No

This will identify the data that is stored in this pair.

Needs to match an agreed upon value and be unique in the list.

Max 255 chars.

value