DEVELOPERS · CHECKID

Create Subject

Create a Subject before initiating an identity check.

Talk to an expert Developer quick start

CONTRACTVersioned API / SDK

AUTHOAuth2 / environment

OUTPUTResponse · result code · evidence

SOURCE-DRIVEN REST CONTRACT

Create Subject

Create the Subject resource that represents the individual who will be the target of a check.

Source contractDigital Trusted Identity Service API And Kafka Specifications · V1.2.260123

POST/v1/create/subject

Bearer + OAuth2 Client Credentials3.3 · Creates SubjectSource p.12

Create the Subject resource that represents the individual who will be the target of a check.

Open in API Explorer ↗

Field	Type	Presence	Description
`lang`	String	O	Response language
`mobile`	String	O	Mobile number
`email`	String	O	Email
`identity_document`	Object	O	Subject identity document
`external_id`	String	O	RP tracking identifier

REQUEST — redacted sampleNO PRODUCTION SECRET

{
  "email": "demo.user@example.invalid",
  "mobile": "+84000000000",
  "external_id": "demo-subject-001",
  "identity_document": {
    "type": "CITIZEN_CARD",
    "value": "<CITIZEN_ID_SAMPLE>"
  },
  "lang": "en"
}

RESPONSEDOCUMENTED SHAPE

{
  "status": 0,
  "message": "SUCCESSFULLY",
  "dtis_id": "<DTIS_TRANSACTION_ID>",
  "subject_id": "<SUBJECT_ID>"
}

Publication boundaryExamples use explicit placeholders; the website does not send requests to a production environment.

API REFERENCE

Source-backed contract: Create Subject

POST · /v1/create/subject

Endpoint & purpose

POST /v1/create/subject. Create a PERSONAL or ENTERPRISE subject before checks are initiated.

Authentication

Bearer . Do not replace this mechanism with assumptions from legacy documentation.

Publication scope

PARTNER. Source: CheckID API contract V1.2.260123 §2.2.6.

Request shape

{
  "owner_type": "PERSONAL",
  "personal_name": "<FULL_NAME>",
  "email": "<EMAIL>",
  "mobile": "<MOBILE>",
  "identity_document": {
    "type": "CITIZEN_CARD",
    "value": "<DOCUMENT_NUMBER>"
  }
}

Response shape

{
  "x-subject-id": "<SUBJECT_ID>",
  "x-billcode-id": "<BILLCODE_ID>",
  "status": 201
}

Failure / recovery

Error semantics must use the raw contract/error catalogue; retry/idempotency/timeout behavior is applied only when a corresponding source defines it.