Documentation

Get familiar with our API and its features

• What can I do with the API?

  The LEM Verify API and webhook integration is organised around REST using standard HTTP response codes and verbs.
  The current version of our API generates unique URLs for verifications, such as Combination, Document and Liveness, along with a notification system in the form of Webhooks.
  When a verification has been processed by the system, LEM Verify will send a POST request (Webhooks) to the selected webhook URL with the result, details and PDF report for further processing by your system.
  
  Base URL: https://api.lemverify.io

  
  
  

  Example Use Case - Generate unique URL for Document and Liveness request

  Your system needs to verify a person's identity for your KYC/AML process. By making a simple API call to "Request a Combination" (a combination of document and liveness verificaiton) you will obtain a unique URL that your end users navigate to in order to securly submit their documents for processing by the LEM Verify systems.
  
  Once the verification results have been processed, our systems will notify your server via a Webhook with the results of the verification for further processing or data storage by your server.

  
  
  

  Example Use Case - Upload an Identity Document for verification (IDV)

  You wish to collect the indviduals identity documents from within your own system (or already have them stored). By making an API call to our Upload a Document endpoint you can upload the identty document and receive a document verification report without having to manually enter any of the individuals information.
  
  Once the verification results have been processed, our systems will notify your server via a Webhook with the results of the verification for further processing or data storage by your server.

  
  
  

  Considerations

  Always use HTTPS.
  
  The web hook post request contains sensitive personal identifiable information, so be very careful where you send this information!
  
  If the account balance is in arrears the webhook will not be sent, so please ensure your account has sufficient credits at all times, as we will not be able to send a POST request after failing due to insufficient credits.
  
  Ensure you send the x-lem-key header, which is case sensitive, with each request. This can be obtained from the Webhooks section of Connections screen in your dashboard.

• Response Codes

  The LEM Verify API returns errors in the form of:

  
  {
     "type": "bad_request",
     "message: "clientRef needs to be set as a String in the body."
  }
  								

  LEM Verify uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided. Codes in the 5xx range indicate an error with LEM Verify's servers (these are rare).

  
  

  Code	Type	Description
  400	bad_request	Your request needs to conform with the format set as per the documentation. The message field will suggest why the error might have occured.
  401	unauthorized	Please ensure you have set the x-lem-key header and that it's the correct key. This is can be obtained in the Webhooks Connections section of your dashboard. This could also be from insufficent credits on account for the service or you are not authorised to use the service, such as AML, without being approved first.
  422	validation_error	The formatting or type of field sent does not conform to the documentation. The message field will suggest which field(s) are incorrect.
  404	verification_not_found	The reuqested verification ID does not exist, ensure it's the System ID returned from the POST Webhook or that from the verification detail section.
  500	internal_server_error	The LEM Server has encountered an error. Please contact support@lemverify.com with the supplied error code.

• Request a Facematch Verification (Recommended)

  To request a Facematch Verification (combination of documents and liveness), the following end point will return the unique URL for your end user to navigate to in order to complete the verification process.

  
  

  To request a Facematch, make a HTTPS POST request to https://api.lemverify.io/api/v1/{account_id}/combination, where {account_id} is your LEM Verify account ID found in the Account Setup section of the dashboard.
  
  The required Headers are:
  Content-Type: application/json
x-lem-key: the api key from the Webhooks page

  
  The body must contain the following parameters:
  
  

  Field	Type	Required	Notes
  clientRef	String	Mandatory	A String containing your own unique client reference number
  redactMe	Boolean	Optional. Default is false	If set to true the docuemts will be redacted as per your settings.
  amlRequired	Boolean	Optional. Default is false	If set to true an AML report will be generated, if enabled, as per your settings.
  requestSmartsearchReport	Boolean	Optional. Default value is true	If this override is set to to false the system will not request a SmartSearch report, even if SmartSearch is enabled as default.
  sendEmail	String	Optional	If you wish to also send an email (standard LEM content through the LEM email server) to a recipient please include a validated email address. The API will not validate the email address you supply.
  sendSms	String	Optional	If you wish to also send an SMS (standard LEM content through the LEM SMS server) to a recipient please include a validated SMS number (with the country code, for example +44788xxxxxxx). The API will not validate the SMS number you supply.

  
  
  

  If the request is successful (200 response) then the response body will look similar to the following:

  
  {
    "id": "8a20ab90-37a1-11e9-a79c-891da1f19982",
    "friendlyId": "vVebr9keyfZ2sctoZkMfBG",
    "url": "https://lemverify.io/combination_verification.html?acc=gc15f4xa-8ea5-4b7e-94c0-cd0303d80aed",
    "balance": 52,
    "deliveryMethods": [
      "API",
    ]
  }
  								

  The deliveryMethods array returns the transmission methods used in this reuqest and will always contain "API". If an email was also sent this array will contain "EMAIL". If an SMS was also sent this array will contain "SMS".
  
  The id is a UUID for the verification, the friendlyId is a short uuid (mostly used for internal referencing at LEM), the balance is remaining credit balance on the LEM Verify account and the url is the url containing the unqiue URL for the verification (where the documents and liveness secure verification takes place).
  
  

  Considerations

  The request will stay in the pending state for 30 days, until either the verificaiton is completed or has been deleted via the LEM Verify dashboard.
  Once a verification is completed it will be retained in the LEM Verify system for 90 days, where it will then be permanently deleted.
• Upload a Document

  Upload a identity document to be processed and verified. This is a two part process; the first part is to obtain the secure signed upload urls for the document type and the second part being the upload of the documents to the associated URL.
  
  The document verification result is asynchronous. The results will be sent via a POST request as a Webhook (please see the Webhooks section below)

  
  Some document types require images of the front (recto) and back (verso) of the identity document. Passports only require the image of the photo page.
  
  

  Document Type	Back/Verso Image Required	Example Images (front and back)	Comments
  PASSPORT	NO		Only a clear image of the biodata (photo) page with MRZ code is required.
  DRIVING LICENSE	YES		Images of both the front and back of the driving license card are required for verification. The issuing country will also be required when uploading the document.
  IDENTITY CARD	YES		Images of both the front and back of the identity card are required for verification. The issuing country will also be required when uploading the document.

  
  
  The image format must be jpeg, png or pdf and under 4.5MB.
  
  The following conditions are recommended when taking a photo of an identity document: ensure the document is within the image capture frame so the edges can be seen, no fingers obstructing the information, no photocopies of the original and avoid glare/shine/white spots on the image.
  
  

  Step 1 - Get the signed URLs

  
  

  Make a HTTPS POST request to https://api.lemverify.io/api/v1/{account_id}/document/upload, where {account_id} is your LEM Verify account id found in the Account Setup section of the dashboard.
  
  The required Headers are:
  Content-Type: application/json
x-lem-key: the api key from the Webhooks page

  
  The body must contain the following parameters:
  
  

  Field	Type	Required	Notes
  clientRef	String	Optional	A String containing your own unique client reference number
  redactMe	Boolean	Optional. Default is false	If set to true the docuemts will be redacted as per your settings.
  documentType	Integer	Optional, but strongly recommended to include this.	The type of document being sent for verifcation. Values are as follows: 1 = PASSPORT 2 = DRIVING LICENSE 10 = IDENTITY CARD Please note that if this paramater is not supplied then verification processing times might be longer that usual and you may incur additional charges.
  documentCountry	String	Optional, but strongly recommended to include this.	The issuin country of the document in the ISO 3166-1 alpha-2 format. Please note that if this paramater is not supplied then verification processing times might be longer that usualand you may incur additional charges.

  
  

  If the request is successfull (200 response) then the response body will look similar to the following:

  
  {
    "id": "8a20ab90-37a1-11e9-a79c-891da1f19982",
    "friendlyId": "vVebr9keyfZ2sctoZkMfBG",
    "rectoUrl": "https://s3.eu-west-1.amazonaws.com/uploads.lemverify.io/...",
    "versoUrl": "https://s3.eu-west-1.amazonaws.com/uploads.lemverify.io/..."
  }
  								

  The id is a uuid for the verification, the friendlyId is a short uuid (mostly used for internal referencing at LEM, that you will see on the dashboard).
  
  Please note: The URLS you receive will expire in 30 seconds, so you need to ensure you uplaod the images within 30 seconds or you will receive a 403 error. If you need a longer expiry please contact support@lemverify.com
  
  

  Step 2 - Uploading the images to the URLs

  
  To upload the images for the verification you need to make a HTTPS PUT request to the URL from the previous step (use the rectoUrl for the front of the document image, and the versoUrl for the reverse side of the document image.)
  
  The required Headers are:
  Content-Type: image/jpeg
  
  For example, you could (very quickly - remember the 30 second expiry time of the URL) CURL to upload the documets, for example:
  curl -H "Content-Type: image/jpeg" -X PUT -T ${image location} -L ${url}
  
  

  Considerations

  Once a verification is completed it will be retained in the LEM Verify system for 90 days, where it will then be permanently deleted.
  
  You will have 30 seconds to upload both sides of a document or the verification will not process.
• Webhooks

  LEM Verify provides webhooks to notify you of processed verifications in the form of a POST request which is sent to your server with the body containing the details in JSON format.

  
  

  You can enable webhooks by going to the Connections section of your dashboard and click the "FREE Setup" button which will show different settings like in the screen shot below:

  
  
  
  

  Once a valid callback URL (https) has been enetered and it returns at 200 code, the webhook is setup and ready to use. You can send test events to ensure your webhook implementation is working as required.

  
  

  Events that trigger a POST request to your server are as follows:
  
  1. Combination verification result
  2. Single Document verification result
  3. Standalone Liveness verification result

  
  

  We strongly recommend that you implement the Webhook Authentication layer, as described in the last section of this documentation.

  
  
  

  Webhook IP Addresses

  Webhook requests will come from one of the following IPs, so please make sure that you whitelist these IPs to receive webhook notifications:

  
  

  • 34.247.111.53 (EU)
• POST Request Webhook

  LEM Verify provides webhooks to notify you of processed verifications in the form a POST request to your server with the body containing the details in JSON format. Please respond with status 200 and an empty body if you have received the POST request.

  
  

  Please note you may receive multiple post requests for the same verificaiton, as the result might be updated at a later date with updated information.

  
  

  The user-agent is LEMVerify/1.0.0

  
  

  Field	Type	Values	Notes
  id	String		UUID for each verification.
  type	String	"COMBINATION" for combination verifications "DOCUMENT" for single document verifications "LIVENESS" for standalone liveness verifications "AML_ALERT" for PEP/Sanction/Adverse Media alerts	The type of verification this event notification is for.
  friendlyId	String		This will be the same as the clientRef used in the verification request. If this field is not supplied then one will be provided.
  processedAt	Signed 32bit integer		The UTC time this verification was processed. It is based on the number of seconds since 00:00:00 1 January 1970.
  startedAt	Signed 32bit integer		The UTC time the verification was started by the end user. It is based on the number of seconds since 00:00:00 1 January 1970.
  deletionAt	Signed 32bit integer		The UTC time the verification will be permanently deleted from the system. It is based on the number of seconds since 00:00:00 1 January 1970.
  result	String	"PASSED" "REFER" "ERROR" "ALERT"	"PASSED" and "REFER" is the LEM Verify recommendation for supplied documentation, liveness video and AML verifications. "ALERT" when the entity has been added to a new PEP/Sanction/Adverse media watchlist. "ERROR" if the state of the verificaiton is in error, please contact support@lemverify.com
  referMessage	String		Explanation of why the supplied information should be investigated further. This field is only sent if the result is REFER.
  balance	int		Remaining credits on balance.
  person	Person	See the Person Object section for more details	Person object containing the extracted and determined information about the individual performing the verification. See the Person Object section for more details. This field will not be present for LIVENESS requests or for AML_ALERT alerts.
  documents	array of Document	See the Document Object section for more details.	Array of Document objects containing the extracted and determined information about each document submitted by the individual performing the verification. See the Document Object section for more details. This field will not be present for LIVENESS requests or for AML_ALERT alerts.
  liveperson	LivePerson	See the LivePerson Object section for more details	LivePerson object containing estimated information about the individual performing the verification. See the LivePerson Object section for more details. This field will not be present for DOCUMENT requests or for AML_ALERT alerts
  alerts	array of Alert	See the Alert Object section for more details	An array of Alert objects containing information about a PEP, Sanction of Adverse Media watchlist they have recently been added to. See the Alert Object section for more details. This field will only be present when a requested on-going screen for an entity joins a new watchlist. This field will only be present for AML_ALERT alerts

  
  

  An example POST body for a Combination that has passed:

  
  content-type: application/json; charset=utf-8
  user-agent: LEMVerify/1.0.0
  x-lemverify-signature:  ???????
  
  {
    "id": "87dcfc90-3732-11e9-bf24-b52fdb098ba2",
    "type": "COMBINATION",
    "friendlyId": "eYsq3N8nNUk6YXzquWURVV",
    "processedAt": 1550898774,
    "startedAt": 1550898774,
    "deletionAt": 1550907684,
    "result": "PASSED",
    "balance": 999,
    "person": {
    	"title": "MR",
      "forename": "JOHN",
      "surname": "DOE",
      "gender": "MALE",
      "dob": {
        "day": 19,
        "month": 11,
        "year": 1982
      },
      "address": {
        "buildingNumber": "10",
        "address1": "Prime Minister First Lord Of The Treasury",
        "address2": "10 Downing Street",
        "postTown": "London",
        "county": "London",
        "country": "England",
        "postCode": "SW1A 2AA"
      }
    },
    "documents": [
      {
        "type": "DRIVING_LICENSE",
        "documentNumber": "TEST90000123456",
        "expiryDate": {
          "day": 1,
          "month": 11,
          "year": 2019
        },
        "issuingCountry": "GB",
        "result": "REFER"
      },
      {
        "type": "PASSPORT",
        "documentNumber": "990099001",
        "expiryDate": {
          "day": 1,
          "month": 11,
          "year": 2019
        },
        "issuingCountry": "GB",
        "result": "PASSED"
      }
    ],
  }
  									

• Person Object

  This object represents the information extracted from the documents about the individual performing the veridicaiton.

  
  

  Field	Type	Values	Notes
  title	String		Identified title of the end user.
  forename	String		Identified forename of the end user.
  surname	String		Identified surname of the end user.
  gender	String	"MALE" "FEMALE" "UNKNOWN"	Identified gender of the end user.
  dob	DOB Object	{ "day": 19, "month": 11, "year": 1982 }	A JSON object to represent the date of birth. Each field is an int.
  address	Address Object	{ "buildingNumber": "10", "address1": "Prime Minister First Lord Of The Treasury", "address2": "10 Downing Street", "postTown": "London", "county": "London", "country": "England", "postCode": "SW1A 2AA" }	A JSON object to represent the address of the individual. The fields sent depend on the address, so treat each as optional apart from the postCode that will always be present in the object. Please note that this address is the end user populated address, unless this functionality is disabled on the account. If disabled then the address will be the one extracted from the document.

  
  

  Example JSON for the Person Object:

  
  {
     "title": "MR",
     "forename": "JOHN",
     "surname": "DOE",
     "gender": "MALE",
     "dob": {
        "day": 19,
        "month": 11,
        "year": 1982
     },
     "address": {
        "buildingNumber": "10",
        "address1": "Prime Minister First Lord Of The Treasury",
        "address2": "10 Downing Street",
    	  "postTown": "London",
        "county": "London",
        "country": "England",
        "postCode": "SW1A 2AA"
     }
  }
  									

• Document Object

  This object represents the information extracted from a document that has been submitted and the authenticity. This object also returns a result for the recommendation of the document for further investigation if required.

  
  

  Field	Type	Values	Notes
  type	String	"DRIVING_LICENSE" "PASSPORT" "IDENTITY_CARD" "UNKNOWN"	Indentified document type.
  documentNumber	String		The unique document number extracted from the document.
  expiryDate	DOB Object	{ "day": 19, "month": 11, "year": 1982 }	A JSON object to represent the expiry date of the document. Each field is an int
  issuingCountry	String		The ISO alpha-2 code representing the country that issued the document.
  result	String	"PASSED" "REFER" "ERROR"	LEM Verify recommendation for supplied document.

  
  

  Example JSON for the Document Object:

  
  {
     "type": "DRIVING_LICENSE",
     "documentNumber": "TEST90000123456",
     "expiryDate": {
        "day": 1,
        "month": 11,
        "year": 2019
     },
     "issuingCountry": "GB",
     "result": "REFER"
  }
  									

• LivePerson Object

  This object represents the estimated information regarding the individual performing the veridicaiton.

  
  

  Field	Type	Values	Notes
  age	int		Estimated age of individual
  gender	String	"MALE" "FEMALE" "UNKNOWN"	Identified gender of the end user.

  
  

  Example JSON for the Person Object:

  
  {
     "age": "38",
     "gender": "MALE"
  }
  									

• Alert Object

  This object will contain data relating a PEP, Sanction or Adverse Media alert when an ongoing search entity has been added to a new watchlist.

  
  

  Field	Type	Values	Notes
  firstName	string		The first and middle names of the individual the watchlist alert is related to
  lastName	string		The last name of the individual the watchlist alert is related to
  entityName	string		The full name of the individual the watchlist alert is related to
  gender	string	"Male" "Female" "None" "Unknown"	The gender of the entity the watchlist alert is related to
  entityId	int		The unique id representing the entity within the watchlist database
  matchScore	int		Confidence score of how closely the list entity matches that of search entity, range of [0, 100]. If a valid score is not available , -1 is returned.
  dateListed	int		The date the entity is added to the watchlist, in the format yyyy-mm-dd
  reasonListed	string		The reason the entity is listed on the watchlist.
  akas	array of Aka		An array of Also Known As (AKA) objects related to the entity that is listed against the watchlist.
  addresses	array of Address		The addresses related to the entity that is listed against the watchlist.
  additionalInfo	array of AdditionalInfo		The reason the entity is listed on the watchlist.

  
  

  Example JSON for the PEP Alert Object:

  
  {
    "id": "ac5c9410-8155-11ea-a158-63c5d15b1f18",
    "friendlyId": "xhtcV8kXDX5hxFxq9XgD5X",
    "alerts": [
      {
        "firstName": "Donald John",
        "lastName": "Trump",
        "fullName": "Donald John Trump Sr",
        "entityId": "LEM1930191",
        "dateListed": "2010-08-05",
        "reasonListed": "National:PEP:Govt Branch Member",
        "entityName": "Trump, Donald John Sr",
        "akas": [
          {
            "type": "AKA",
            "fullName": "David Denison"
          },
          {
            "type": "AKA",
            "fullName": "ديفد دنيسون"
          }
        ],
        "additionalInfo": [
          {
            "type": "DOB",
            "fullName": "1946-06-XX"
          },
          {
            "type": "Occupation",
            "fullName": "President of the United States (January 20, 2017 - January 20, 2021)."
          },
          {
            "type": "Other",
            "fullName": "Link to WorldCompliance Online Database"
          },
          {
            "type": "Other",
            "fullName": "Negative News Alert"
          },
          {
            "type": "Other",
            "fullName": "Sources of Record Information"
          },
          {
            "type": "PlaceOfBirth",
            "fullName": "New York City, New York, United States"
          }
        ],
        "addresses": [
          {
            "country": "United States"
          },
          {
            "street1": "1600 Pennsylvania Ave NW",
            "city": "Washington",
            "stateProvinceDistrict": "District of Columbia",
            "postalCode": "20500-0003",
            "country": "United States"
          }
        ]
      }
    ]
  }
  									

• Webhook Authentication

  LEM Verify signs webhook requests so you can (optional but we strongly recommended implementating due to the senstive data exposed in the webhooks) verify that requests are generated by LEM Verify and not a third-party pretending to be LEM Verify. This isn't required, but offers an additional layer of security.
  
  

  Verifying Request Signatures

  LEM Verify includes an additional HTTP header with webhook POST requests, X-LEMVerify-Signature, which will contain the signature for the request. To verify a webhook request, generate a signature using the same key that Mandrill uses and compare that to the value of the X-LEMVerify-Signature header.
  
  

  Get Your Webhook Authentication Key

  When you create a webhook, a key is automatically generated. You can also view and reset the key from the Connections page from your dashboard in the Webhooks section.
  
  

  Generate a Signature

  In your code that receives or processes webhook requests:
  
  1. Create a string starting with your webhook URL.
  2. Append the id from the POST request to the string.
  3. Append the friendlyId from the POST request to the string.
  4. Append the type from the POST request to the string.
  5. Append the result from the POST request to the string.
  6. Hash the resulting string with HMAC-SHA1, using your webhook's authentication key to generate a binary signature.
  7. Base64 encode the binary signature.
  8. Compare the binary signature that you generated to the signature provided in the X-LEMVerify-Signature HTTP header.
  
  Leading on from the example POST request in the Webhooks section above, an example signiture is as follows:
  
  webhook url: https://mywebservice.acme.com/lemresults
key from your dashboard: 6ba1225b-6c50-4a24-ba20-2b8f2a7a0e7e
id from POST request from LEM Verify: 87dcfc90-3732-11e9-bf24-b52fdb098ba2
friendlyId from POST request from LEM Verify: 87dcfc90-3732-11e9-bf24-b52fdb098ba2
type from POST request from LEM Verify: COMBINATION
result from POST request from LEM Verify: PASSED
  
  This generates a string https://mywebservice.acme.com/lemresults87dcfc90-3732-11e9-bf24-b52fdb098ba287dcfc90-3732-11e9-bf24-b52fdb098ba2COMBINATIONPASSED that has a final signature of ?????

• Download Documents

  To retrieve the originally submitted documents by the end-user you can call the following endpoint that returns urls to directly download the document associated with the verificaiton. The download url is signed against the requesting IP address (/32) that has a valid x-lem-key and the webhooks enabled.
  
  Please note: the url will expire 5 minutes after the requestand can only be downloaded from the same IP address (/32) that requested the download url.
  
  To request a the document download url(s), make a HTTPS GET request to https://api.lemverify.io/integrations/v1/webhooks/{accountId}/document/{systemId}/url, where {accountId} is your LEM Verify account ID found in the Account Setup section of the dashboard and where {systemId} is the id sent through in the "POST Request Webhook" request (or you can use the System ID that is on the verificaiton page detail section).
  
  The required Headers are:
  Content-Type: application/json
x-lem-key: the api key from the Webhooks page
  
  The response will be a 200 with the following body:

  
  {
    "report": "signed url of the LEM Verify report",
    "amlReport": "signed url of the LEM Verify AML report (if enabled and available)",
    "documentFront": "signed url of document front image",
    "documentBack": "signed url of document back image (only present for Driving License and Identity Documents types)",
    "redactedReport": "signed url of the redacted LEM Verify report (if enabled and available)",
    "smartsearchReport": "signed url of the SmartSearch report (if enabled and available)",
    "supportingDocument": "signed url of the supporting document uploaded by the end-iser (if enabled and available)"
  }
  									

  If the verification ID does not exist a 404 code will be returned.
  
  All download url requests are logged in the "Audit Trail" section of a requested verificaiton. The audit logs can be viewed at the bottom of a verificaiton page from your LEM Verify dashboard.

• Anti Money Laundering (AML)

  For snapshot Politically Exposed Person (PEP), Sanction and Adverse Media checks and on-going (daily) monitoring. If an individual is added to one of our global watchlists a webhook and email will be generated with details of the alert, along with the details displayed in your dashboard. It is strongly recommended to implement the Webhooks in order to trigger other KYC and AML procedures. Please see On-Going PEP, Sanction, Adverse Media Screening blog for more product details.
  
  

  To request an On-Going Screen, make a HTTPS POST request to https://api.lemverify.io/api/v1/{account_id}/ongoing, where {account_id} is your LEM Verify account ID found in the Account Setup section of the dashboard.
  
  If you are using the Advanced AML Service, an On-Going screen will also be created for which you will receive webhooks for if the individual is placed on another watchlist.
  
  The required Headers are:
  Content-Type: application/json
x-lem-key: the api key from the Webhooks page

  
  The body must contain the following parameters:
  
  

  Field	Type	Required	Notes
  clientRef	String	Mandatory	Your unique reference number to associate with the on-going screen
  forename	String	Mandatory	A String containing the forename of the individual you wish to create the on-going screen for
  middle	String	Optional	A String containing the middle name of the individual you wish to create the on-going screen for
  surname	String	Mandatory	A String containing the surname of the individual you wish to create the on-going screen for
  dob	String	Mandatory	A String containing the dob of the individual you wish to create the on-going screen for, in the format dd/mm/yyyy
  gender	String	Mandatory	A String containing the gender of the individual, either "Male" or "Female"

  
  
  

  If the request is successful (200 response) then the response body will look similar to the following:

  This object will contain data relating a PEP, Sanction or Adverse Media alert when an ongoing search entity has been added to a new watchlist.

  
  

  Field	Type	Notes
  id	string	Unique ID issued by LEM Verify to track the request
  passed	boolean	If the AML check has been passed against the scorecard used, then the result will be true. false will be returned if the score hasnt reached the threshold set by the scorecard.
  person	Object	Object representing the individuals details that the search was against.
  results	AML Result object	Object containing the results from the AML check for the services that are enabled.

  
  Example JSON response:

  
  {
    "id": "d263c120-8a39-11ef-83de-5fc02cafb795",
    "passed": true,
    "person": {
      "givenNames": "John",
      "surname": "Smith",
      "dob": "1940-11-10",
      "dobDay": 10,
      "dobMonth": 11,
      "dobYear": 1940,
      "address": {
        "formatted": "1 ACME ROAD, LONDON, SE1 5AS"
      }
    },
    "results": {
      "insolvencyPassed": true,
      "ccjPassed": true,
      "creditPassed": false,
      "erPassed": true,
      "address": {
        "recency": "09/05/2014",
        "er": "ER2000,ER2001,ER2002,ER2003,ER2004,ER2012,ER2013,ER2014",
        "tel": "01234567890",
        "telName": "MR J SMITH",
        "gone": "N"
      },
      "mortalityPassed": true,
      "pepPassed": true,
      "sanctionsPassed": true
      "linkedAddresses": [
        {
          "fullName": "MR JOHN SMITH",
          "address": "APARTMENT 1, HARBOUR REACH, THE BOULEVARD, IMPERIAL WHARF, SW9 2FS",
          "recency": "29/09/2013",
          "residency": "2014",
          "source": "Subject - DOB"
        },
        {
          "fullName": "MR JOHN SMITH",
          "address": "19 HANOVER SQUARE, LONDON, W3S 1GN",
          "recency": "04/03/2014",
          "residency": "2014",
          "source": "Subject - Forwarding"
        }
      ],
      "companyDirectorships": [
        {
          "companyName": "ACME FINANCE LTD",
          "matchType": "Name & DOB",
          "dateAppointed": "07/02/2010",
          "companyRegNo": 8457069,
          "registeredOffice": "62 SOUTHWARK BRIDGE, LONDON, SE1 0AS",
          "appointments": [
            {
              "name": "MR JOHN SMITH",
              "address": "1 ACME ROAD, LONDON, SE1 5AS",
              "dob": "10/11/1940",
              "occupation": "DIRECTOR",
              "nationality": "BRITISH",
              "appointmentDate": "22/03/2013",
              "appointmentType": "Current Director"
            }
          ]
        }
      ]
    }
  }
  								

  Considerations

  Once a verification is completed it will be retained in the LEM Verify system for 90 days, then it will then be permanently deleted, so we recommend downloading the report pdf.

• On-going Screening

  For snapshot Politically Exposed Person (PEP), Sanction and Adverse Media checks and on-going (daily) monitoring. If an individual is added to one of our global watchlists a webhook and email will be generated with details of the alert, along with the details displayed in your dashboard. It is strongly recommended to implement the Webhooks in order to trigger other KYC and AML procedures. Please see On-Going PEP, Sanction, Adverse Media Screening blog for more product details.
  
  

  To request an On-Going Screen, make a HTTPS POST request to https://api.lemverify.io/api/v1/{account_id}/ongoing, where {account_id} is your LEM Verify account ID found in the Account Setup section of the dashboard.
  
  The required Headers are:
  Content-Type: application/json
x-lem-key: the api key from the Webhooks page

  
  The body must contain the following parameters:
  
  

  Field	Type	Required	Notes
  forename	String	Mandatory	A String containing the forename of the individual you wish to create the on-going screen for
  middle	String	Optional	A String containing the middle name of the individual you wish to create the on-going screen for
  surname	String	Mandatory	A String containing the surname of the individual you wish to create the on-going screen for
  dob	String	Mandatory	A String containing the dob of the individual you wish to create the on-going screen for, in the format dd/mm/yyyy
  clientRef	String	Mandatory	Your unique reference number to associate with the on-going screen

  
  
  

  If the request is successful (200 response) then the response body will look similar to the following:

  This object will contain data relating a PEP, Sanction or Adverse Media alert when an ongoing search entity has been added to a new watchlist.

  
  

  Field	Type	Notes
  id	string	Unique ID issued by LEM Verify to track the request
  friendlyId	string	A shorter unique ID that is displayed in the LEM Verify dashboard
  alerts	Array of Alert objects	The alerts associated with any watchlist matches. If the array is empty the individual is not associated with any watchlists.

  
  Example JSON:

  
  {
    "id": "ac5c9410-8155-11ea-a158-63c5d15b1f18",
    "friendlyId": "xhtcV8kXDX5hxFxq9XgD5X",
    "alerts": [
      {
        "firstName": "Donald John",
        "lastName": "Trump",
        "fullName": "Donald John Trump Sr",
        "entityId": "LEM1930191",
        "dateListed": "2010-08-05",
        "reasonListed": "National:PEP:Govt Branch Member",
        "entityName": "Trump, Donald John Sr",
        "akas": [
          {
            "type": "AKA",
            "fullName": "David Denison"
          },
          {
            "type": "AKA",
            "fullName": "ديفد دنيسون"
          }
        ],
        "additionalInfo": [
          {
            "type": "DOB",
            "fullName": "1946-06-XX"
          },
          {
            "type": "Occupation",
            "fullName": "President of the United States (January 20, 2017 - January 20, 2021)."
          },
          {
            "type": "Other",
            "fullName": "Link to WorldCompliance Online Database"
          },
          {
            "type": "Other",
            "fullName": "Negative News Alert"
          },
          {
            "type": "Other",
            "fullName": "Sources of Record Information"
          },
          {
            "type": "PlaceOfBirth",
            "fullName": "New York City, New York, United States"
          }
        ],
        "addresses": [
          {
            "country": "United States"
          },
          {
            "street1": "1600 Pennsylvania Ave NW",
            "city": "Washington",
            "stateProvinceDistrict": "District of Columbia",
            "postalCode": "20500-0003",
            "country": "United States"
          }
        ]
      }
    ]
  }
  								

• Change Log

  Version 2.3 (20/10/2021)

  Deprecation of the Request Document Verification and Request Liveness Verificaiton endpoints, in favour of the Request a Facematch Verification.

  
  

  Version 2.2 (12/09/2020)

  Updated the Facematch endpoint to allow the option of also sending out an Email and/or SMS.

  
  

  Version 2.1 (07/06/2020)

  Addition of the supportingDocument field in the download documents service, that will be present if an end-user has supplied this document.

  
  

  Version 2.0 (30/04/2020)

  Public release of our Anti-Money Laundering (AML) APIs, please see "Anti-Money Laundering (AML)" section.

  
  

  Version 1.9 (18/04/2020)

  Release of our "On-going Screening" alert API for Politically Exposed Person (PEP), Sanction and Adverse Media matching and alerts. "POST Request Webhook" updated to include the alerts object with details of the alert match in real-time.

  
  

  Version 1.8 (28/12/2019)

  Updated the "Upload a Document" endpoint so that the reverse (verso) of the document can also be uploaded, which depends on the document type. The reverse is required for Driving License and Identity Card document types, along with the issuing country of the document.

  
  

  Version 1.7 (26/08/2019)

  Updated "Request a Combination Verification" endpoint to include optional redactMe and amlRequired for enabling redaction and AML reports respectively.

  
  

  Version 1.6 (11/08/2019)

  Updated "Request a Combination Verification" endpoint to include optional SmartSearch report override.

  
  

  Version 1.5 (04/08/2019)

  Updated "Download Documents" endpoint to include additional reports.

  
  

  Version 1.4 (30/07/2019)

  Added the "Download Documents" endpoint, that allows you to retrieve the originally submitted documents by the end-user for a verification.

  
  

  Version 1.3 (22/06/2019)

  "POST Request Webhook" updated to include the redactedReport base64 encoded pdf if present and redaction is enabled.

  
  

  Version 1.2 (20/05/2019)

  "Upload a Document" endpoint moved to public from private beta, allowing verificaiton of uploaded documents.

  
  

  Version 1.1 (19/05/2019)

  Connections field added to the Post Request Webhook, that represents data returned from 3rd party systems that are connected to your LEM Verify account.

  
  

  Version 1.0 (07/03/2019)

  Initial release of the public API and Webhooks.