API Versions This documentation relates to Version 5, the current version of the greenID API. Version 5 became available to customers as of .
In the Web Method Details section, there is a complete discussion of the parameters that are passed to, and returned from, the Web Service methods in the API. This section provides additional conversation about the most important elements, what those elements mean, and their relevance to the verification process.
Interpreting the sourceList
A call to any method in the greenID API will return, as part of the CurrentStatusV5
object, a sourceList
element. The sourceList
contains a list of data sources that can contribute to the person's verification attempt. This list of sources is not fixed, it is computed based on the current state of the person's verification attempt, so it can be useful because it can indicate which data sources are not worth attempting, and also which data sources, if passed, will result in the person being verified immediately (we refer to this as "one source left").
Consider the snippet of XML below:
<sourceList> <source> <available>true</available> <name>aDataSource</name> <notRequired>false</notRequired> <oneSourceLeft>false</oneSourceLeft> <order>1</order> <passed>false</passed> <state>EMPTY</state> <version>1</version> </source> ... <sourceList>
sourceList
element. One of the most important elements here is the name element, which contains the name of the data source, which is "aDataSource" in this case. This name is used to refer to this data source when calling setFields
. The other important elements are described below:available
- if the data source is able to be used, then this element will contain "true", otherwise it will contain "false". If a data source is not available (usually because greenID cannot currently access the data source), thensetFields
should not be called for that data source, since the call will fail.passed
- if the data source has been previously attempted, and passed, then this element will contain "true", otherwise it will contain "false". If the data source is passed, then callingsetFields
for that data source will fail, and have no effect.oneSourceLeft
- this element indicates if this data source is sufficient to get the person completely verified. If this element contains "true", then callingsetFields
for this data source, and having a successful outcome, will be enough to get the person completely verified. The value is computed based on the current state of the person's verification attempt, so it can change after calls tosetFields
.state
- while the passed element provides a simple yes/no indication of whether the person has successfully completed this data source, the state element provides a more detailed indication. Please refer to the detailed description of theCheckResult
type below for the list of values that may appear in this field.notRequired
- this element indicates whether this data source can contribute to the person's verification attempt. If this field contains "true", then there is no value in attempting this data source, since it cannot make any difference the person's verification attempt. A call tosetFields
for this data source would be wasted.
Interpreting the sourceFields
A call to getFields
for a given data source (using the name provided in the sourceList
, detailed above), will return a list of data fields required for that data source. If the fields are filled, by collecting data from the person being verified, and passed to setFields
, then the data source will be checked. However, there is a lot of detail in the return object from getFields
, and it is important to know what to do with that information.
The main aim of the getFields
method is to provide the customer with enough detail to render HTML input fields to collect input from the person being verified. GreenID also generates an HTML fragment that can be used directly, if desired. This is discussed in more detail later.
The getFields
method returns a CurrentStatusV3
object, like all the other methods, but with the sourceFields
member populated. Below is a snippet of XML from a SOAP envelope:
<sourceFields> <fieldList> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_number</value> </attribute> <attribute> <name>class</name> <value>form-control required</value> </attribute> <attribute> <name>aria-required</name> <value>true</value> </attribute> <label>Licence number</label> <name>greenid_aDataSource_number</name> <type>text</type> <value/> </sourceField> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_givenname</value> </attribute> <attribute> <name>class</name> <value>form-control namevalidation required</value> </attribute> <attribute> <name>aria-required</name> <value>true</value> </attribute> <label>First name</label> <name>greenid_aDataSource_givenname</name> <type>text</type> <value>Test</value> </sourceField> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_middlename</value> </attribute> <attribute> <name>class</name> <value>form-control</value> </attribute> <attribute> <name>aria-required</name> <value>false</value> </attribute> <label>Middle name(s)</label> <name>greenid_aDataSource_middlename</name> <type>text</type> <value>Q</value> </sourceField> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_surname</value> </attribute> <attribute> <name>class</name> <value>form-control namevalidation required</value> </attribute> <attribute> <name>aria-required</name> <value>true</value> </attribute> <label>Surname</label> <name>greenid_aDataSource_surname</name> <type>text</type> <value>Citizen</value> </sourceField> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_dob</value> </attribute> <attribute> <name>class</name> <value>form-control dobvalidation required</value> </attribute> <attribute> <name>aria-required</name> <value>true</value> </attribute> <label>Date of birth (dd/mm/yyyy)</label> <name>greenid_aDataSource_dob</name> <type>text</type> <value>01/01/1980</value> </sourceField> <sourceField> <attribute> <name>id</name> <value>greenid_aDataSource_tandc</value> </attribute> <attribute> <name>class</name> <value>required</value> </attribute> <attribute> <name>aria-required</name> <value>true</value> </attribute> <label>I consent to the information above being checked with the Issuer or Official Record Holder</label> <name>greenid_aDataSource_tandc</name> <type>checkbox</type> </sourceField> ... </fieldList> ... </sourceFields>
Each sourceField
element represents a single data field that is required for the data source. The fieldList
element contains a list of sourceFields
elements, which, in totality, represent all the fields required for the data source.
sourceFields
element are:name
- contains the name of the field. This name is used when the data fields are passed tosetFields
. Because of this, the names can be a little long. Theid
is the suggestedid
for the field if it is rendered in HTML. The names are also prefixed with "greenid_" in order to avoid name clashes with anything else that might be on the customer's page.label
- please see the section about Labels.type
- indicates the type of the field, and this corresponds to an HTML input field type. Most fields are "text" fields. In the example above, thegreenid_aDataSource_tandc
field is a checkbox, which should be rendered using an HTML checkbox input field.value
- contains any pre-existing value. For example, from the snippet above, thegreenid_aDataSource_givenname
field has a pre-existing value of "Test". Customers should include this value when rendering HTML input fields.
Each sourceFields
element also contains a list of attribute
elements. These attributes are intended to be applied to HTML input fields that are rendered to gather input from the person being verified. The name
element is the intended name of the attribute, and the value
element is the intended value of the attribute. For example, from the snippet above, the greenid_aDataSource_number
input field is intended to have the HTML attributes "id='greenid_aDataSource_number' class='required'"
applied when rendered in HTML.
The goal is that a customer can read the fieldList
element and get enough information to render HTML dynamically. Of course, given that the fields and their names are not subject to frequent change, their values can be assumed.
The sourceFields
element also contains an element called rawData
that contains a pre-rendered HTML fragment that can be used directly by the customer, if desired. From the example above, the rawData
element contains:
<rawData><![CDATA[<?xml version="1.0"?> <sourcefields> <div class="row"> <div class="form-group col-sm-3"> <label for="greenid_aDataSource_number" class="control-label">{{{aDataSource_number_label}}} <span class="greenid-helpicon" title="{{{aDataSource_number_tooltip}}}"> <span class="greenid-sr-only">{{{aDataSource_number_tooltip}}}</span> </span> </label> <input type="text" name="greenid_aDataSource_number" id="greenid_aDataSource_number" class="required" value=""/> </div> </div> <div class="row"> <div class="form-group col-sm-4"> <label for="greenid_aDataSource_givenname">{{{aDataSource_givenname_label}}}</label> <input type="text" name="greenid_aDataSource_givenname" id="greenid_aDataSource_givenname" class="form-control namevalidation required" value="Test"/> </div> <div class="form-group col-sm-4"> <label for="greenid_aDataSource_surname">{{{aDataSource_surname_label}}}</label> <input type="text" name="greenid_aDataSource_surname" id="greenid_aDataSource_surname" class="form-control namevalidation required" value="McTestie"/> </div> </div> <div class="row"> <div class="form-group col-sm-3"> <label for="greenid_aDataSource_dob">{{{aDataSource_dob_label}}}</label> <input type="text" name="greenid_aDataSource_dob" id="greenid_aDataSource_dob" class="form-control dobvalidation required" value="01/02/1980"/> </div> </div> <div class="checkbox"> <label for="greenid_aDataSource_tandc"> <input type="checkbox" name="greenid_aDataSource_tandc" id="greenid_aDataSource_tandc" class="required"/> {{{aDataSource_tandc_label}}}</label> </div> </sourcefields>]]> </rawData>
The HTML fragment is the result of the most basic strategy for taking the input fields, as listed in the fieldList
element, and transforming them into HTML. The customer is free to use this HTML fragment, or ignore it.
Interpreting gbgAlert
A call to any method in the greenID API will return, as part of the CurrentStatusV5
object, a gbgAlert element. The gbgAlert contain the results of the GBG Alert evaluations.
If the overall status is NOT_ATTEMPTED
then the gbgAlert
element will contain no other data. For example:
|
If the overall status is NO_ALERT_RAISED, the gbgAlert element may, or may not, contain 'raisedAlerts'. This is because NO_ALERT_RAISED can mean:
- No alerts have ever been raised OR
- There were alerts raised and locked, but an administrator has 'unlocked' them all - therefore there are no unactioned/of concern Alerts raised.
|
If the overall status is ALERTS_RAISED, then the top-level element will contain the overall Alert status, as well as a score (see note below) and a list of 'raisedAlerts' (i.e. configured rules which have been triggered.. The 'raisedAlerts' will contain a list of 'raisedAlert' elements, each containing information about an alert rule raised.
For example:
|