Getting started
Core resources
Other

Digital Identity

Info
Digital Identity is available in both API versions 1 and 2. However, API version 1 will be deprecated in the future, so new integrations should use API version 2. Requests require the write.digital_identity OAuth scope.

Field descriptions

See the OpenAPI specification for the full schema (including optional fields).
{
  "id": { "type": "string" }, // (Required) Unique identifier for the data
  "document_type": { "type": "string" }, // (Required) Must be "none"
  "credential_type": { "type": "string" }, // (Required) Must be "digital_identity"
  "data": { // { "type": "object" }, (Required)
    "credential": { // { "type": "object" }, (Required)
      "full_name": { "type": "string" }, // (Required)
      "date_of_birth": { "type": ["string", "null"], "format": "date" }, // (Optional) Encouraged to be included if available. Date format: "YYYY-MM-DD"
      "identity_document_validity": { "type": "string" }, // (Required) Must be one of "manual", "government_database", "verifiable_credential"
      "identity_document_liveness": { "type": "string" }, // (Required) Must be one of "automated", "in_person",
      "identity_document_person_match": { "type": "string" }, // (Required) Must be one of "manual", "automated", "government_database"
    },
    "partner_chain": { "type": ["array", "null"] } // (Optional unless otherwise specified) Array of objects to specifiy partner institutions, e.g. [{ "name": "Partner Organization" }]
  }
}

Leveraging Digital Identity fields

Identity validations

Your payload must include fields that describe the level of validations involved in your assessment process.
This allows us to understand the depth of verification taken in assessing this Digital Identity submission.
ValidationFieldDetails
Have you confirmed that the user has a valid government identity document?identity_document_validitymanualYes, a human sighted the document.
government_databaseYes, via verification against a government database (e.g. DUKCAPIL, DVS).
verifiable_credentialYes, via verification using a cryptographically verifiable source/format (e.g. Singpass, ISO mDL).
Have you confirmed that this document was received from a live user?identity_document_livenessautomatedYes, via an automated liveness verification system (e.g. Amazon Rekognition).
in_personYes, the document was provided in person.
Have you confirmed that the user is the same person appearing on the government identity document?identity_document_person_matchmanualYes, a human compared a photo of the user to the photo on the government identity document
automatedYes, an automated system was used to compare a photo of the user to the photo on the government identity document (e.g. Amazon Rekognition)
government_databaseYes, an automated system was used to compare a photo of the user to a photo stored in a government database (e.g. FVS)
Info
If you’re unable to label your submission based on the responses we’ve provided, please reach out to us for further support.

Partner chain

The partner_chain field captures intermediate relationships in multi-layered partner hierarchies that aren't represented elsewhere in the integration. It improves the granularity of analytics SEEK Pass can provide to you.Click here for more details.

Sample payload

{
  "id": "fa651300-b91a-49cb-8ee7-cac68b3fdf74",
  "document_type": "none",
  "credential_type": "digital_identity",
  "data": {
    "credential": {
      "full_name": "John Doe",
      "date_of_birth": "1990-01-30", // Optional but encouraged to be included if available
      "identity_document_validity": "manual",
      "identity_document_liveness": "in_person",
      "identity_document_person_match": "government_database"
    }
  }
}