The API enables you to create and manage customer profiles and search for customers based on their unique customerId or personal identifier. You can also use our API to verify a provided phone number and email address exists.
Benefits
Customer Management
Retrieve Personal Identifying Information (PII) data about a customer using their customerId. If you do not have their customerId, you can search for the customer using one or more of the supported query filters.
| Parameter | Definition |
|---|---|
customerId | Unique customer identifier. |
givenName | The given name (also known as the first name) associated with the customer profile. |
familyName | The family name (also known as the last name) associated with the customer profile. |
postCode | Postcode of the address associated with the customer profile. |
phoneNumber | The phone number associated with the customer profile. (Phone number can be the home, work, fax, or mobile number). |
dateOfBirth | The birthday and time associated with the customer profile, in ISO 8601 format (i.e. “2000-07-19T09:14:44.568Z”) |
Customer Verification
Verify the customer’s email address and/or phone number exists through the Customer API. The API will verify that the email address and phone number exist but not confirm the possession. Confirm possession by sending a One-time Passcode (OTP).
We currently verify the mobile numbers registered to a network in the United Kingdom only. The endpoint assumes the country is the United Kingdom unless you prefix the mobile phone number with its international dialling code (e.g., +44 or 0044).
How does customer verification work?
The email address and phone number are validated similarly. Below is what a successful validation flow looks like.
- You initiate the call and provide the
emailAddressorphoneNumber, depending on your chosen verification endpoint. - The endpoint returns
trueorfalseto confirm the provided email address or phone number is verified.
Verification statuses
Both endpoints will return true or false depending on whether the email address or phone number is verified.
| Status | Validation Type | Description |
|---|---|---|
true | Phone | The phone number is valid and the number is verified. |
false | Phone | The phone number is not valid because of a non-UK number format or the format is valid but not verified with network lookup or a valid number but it is not active on a network. |
true | The mailbox exists and is reachable. Or we were unable to conclusively verify or invalidate the email address. | |
false | The mailbox is disabled, does not exist, is full or the syntax of the specified email address is incorrect. The email address could belong to a disposable email provider, seed, spam trap, black hole, technical role account or inactive domain. |
Inbound Open Banking
NewDay sources Open Banking data and uses it to improve the accuracy of our affordability strategies and outcomes for new and existing customers. The TPP (third party provider) for sourcing the Open Banking data is D.one, built by the ClearScore group.
Open Banking data is primarily account and transactions associated to bank accounts that are held in the customer’s name for which they have provided Open Banking permissions, via an AISP permissions journey.
You must have the correct customer identifier customerId for which you are enquiring about it, this is the Customer Number from FiServ or CustomerId when using Stratus.
- Provide a standard NewDay MSI service authorization JWT token.
- Be on the internal NewDay network to access this API currently, and be whitelisted in our API firewall.
Authorisation may change in the future to accept customer auth tokens.
- You use customers personal information.
- You want to display the customer their best actions to increase their credit. Credit coach insights.
- You validate Customer E-mails, mobiles and addresses, replacing the legacy Fabric.Shared.DNX APIs
Although the updates made to customer preference options are immediately saved to the client’s account, it takes up to 24 hours to be exported to the data warehouse and for users to implement the change. For example, you have updated a client’s preferred mode of receiving communications to email from text. So, after 24 hours, the client receives all communications via email, instead of text messages.
If you are actioning communications based on a live API call to this service, this section is not relevant to you.
Was this page helpful?