moj noms apvs 0063 hwf benefit check
Technical Spike to understand the Help With Fees (HWF) Benefit Check web service.
See technical spike 0062 LAA Benefit check for requirements.
The Help With Fees digital service includes a call to the same DWP-LAA API link for checking income/benefit eligibility.
They have thus developed a proxy to the API which is hosted on AWS and wraps the LAA SOAP service in a REST endpoint.
The existing Ruby code for the HWF service which calls this endpoint can be found here:
Specs are available which illustrate usage:
The HWF proxy service is presented as a single HTTP endpoint {API_PROXY_URL}:PORT/api/benefit_checks
This endpoint accepts requests in the form of a POST which contain the set of parameters required by the underlying LAA check:
-
id- API token provided by authorised client -
ni_number- the National Insurance number of the individual to be checked -
surname- Surname of the individual to be checked -
birth_date- DoB for the individual to be checked. Format: %Y%m%d
The service is secured with the inclusion of an API token which must be supplied by our client.
The request responds in JSON format with the standard LAA response values for the results of a check:
{
benefit_checker_status: 'Yes'
}
Possible values for this field are the same as the underlying LAA API:
- Yes
- No
- Undetermined
- Deceased
- Deleted
- Superceded
The design of this component will be identical to that documented for the LAA benefit check API, as documented in the spike: 0062 LAA Benefit check.
The exception to this will be the SOAP Client section. This will be replaced by REST client sub-component.
The variation on this architecture is illustrated below:
As shown, the SOAP API client will be replaced with a REST client which calls the HWF proxy with the required data.
Otherwise, the architecture will remain the same as documented
There are no service usage costs.
We cannot currently confirm that this service will be usable by the APVU service, for the reason that it is currently deployed in such a way as to be usable only by the existing HWF service.
HWF firstly need to take ownership of the API proxy component from the support team to run it as a service which would be reusable by other projects. We understand that this will also require (relatively minor) changes to allow the service to authenticate mutiple clients using it's token-based approach.
Assuming that this was achieved within the project timescales for Beta then this service would be otherwise technically feasible - being a simple REST wrapper for the LAA service.