Dukcapil Data sandbox

Sandbox payloads for the Stateless Dukcapil Data endpoint.

POST /api/v3/verifications/indonesia/dukcapil-passthrough

When your account is in sandbox mode, these payloads return the outcomes shown below. Any other valid payload is answered as a no-match — HTTP 200 with isValid set to false. Values are case-sensitive. transactionId and createdAt are generated per request, and metadata is echoed back from your request. See Sandbox introduction for the full matching rules.

Send only the keys shown in each request. Matching is exact on the key set, so adding an optional field such as gender or address to a documented payload turns it into a no-match.

Verified

VERIFIED — NIK, name and date of birth match

Request

{
  "nik": "3171010101900021",
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": true,
    "nik": "3171010101900021",
    "name": "BUDI SANTOSO",
    "dateOfBirth": "1990-01-01"
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

VERIFIED — Identity and optional fields match

Request

{
  "nik": "3171010101900025",
  "name": "DEWI LESTARI",
  "dateOfBirth": "1995-03-22",
  "placeOfBirth": "JAKARTA",
  "gender": "Female"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": true,
    "nik": "3171010101900025",
    "name": "DEWI LESTARI",
    "dateOfBirth": "1995-03-22"
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

Optional fields are checked against the Dukcapil record but are not echoed in the response. Send them exactly as shown — this payload only matches with both placeOfBirth and gender present.

Review needed

REVIEW_NEEDED — Core identity matches, optional field does not

Request

{
  "nik": "3171010101900024",
  "name": "AGUS PRATAMA",
  "dateOfBirth": "1985-08-17",
  "noKk": "3171010101000001"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": false,
    "nik": "3171010101900024",
    "name": "AGUS PRATAMA",
    "dateOfBirth": "1985-08-17"
  },
  "verificationStatus": "REVIEW_NEEDED",
  "verificationStatusCode": 2,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

NIK, name and date of birth matched, but an optional field you sent (here noKk) did not. isValid is false because only VERIFIED counts as valid — branch on verificationStatus to route these to manual review.

Rejected

A rejection is a completed verification, not an error: success is true and HTTP status is 200. In live mode a rejection is billed.

REJECTED — Name does not match

Request

{
  "nik": "3171010101900022",
  "name": "BUDI SANTOSA",
  "dateOfBirth": "1992-05-12"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": false,
    "nik": "3171010101900022",
    "name": "WRONG NAME",
    "dateOfBirth": "1992-05-12"
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

REJECTED — Date of birth does not match

Request

{
  "nik": "3171010101900023",
  "name": "SITI RAHAYU",
  "dateOfBirth": "1980-01-01"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": false,
    "nik": "3171010101900023",
    "name": "SITI RAHAYU",
    "dateOfBirth": "1980-01-01"
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

REJECTED — Not verified, unmatched payload fallback

Request

{
  "nik": "3171019999999999",
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 200

{
  "success": true,
  "message": "Indonesia Dukcapil processed successfully",
  "data": {
    "isValid": false,
    "nik": "3171019999999999",
    "name": "BUDI SANTOSO",
    "dateOfBirth": "1990-01-01"
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

This NIK matches no documented scenario, so it takes the no-match fallback. Worth firing once to confirm that an unknown NIK never reaches live Dukcapil.

Validation failures

All validation failures return HTTP 400 with code set to VALIDATION_FAILED and the same message; only errors differs. Validation runs before any fixture matching, so these behave identically in sandbox and live. transactionId is null and no transaction row is written.

VALIDATION_FAILED — NIK missing

Request

{
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "nik": ["The nik field is required."]
  },
  "transactionId": null,
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

VALIDATION_FAILED — NIK not 16 digits

Request

{
  "nik": "31710101",
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "nik": ["The nik must be 16 digits."]
  },
  "transactionId": null,
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

VALIDATION_FAILED — Name missing

Request

{
  "nik": "3171010101900021",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "name": ["The name field is required."]
  },
  "transactionId": null,
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

VALIDATION_FAILED — Date of birth missing

Request

{
  "nik": "3171010101900021",
  "name": "BUDI SANTOSO"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "dateOfBirth": ["The date of birth field is required."]
  },
  "transactionId": null,
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

VALIDATION_FAILED — Trust flow fields sent to a stateless endpoint

Request

{
  "nik": "3171010101900021",
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01",
  "trustFlowId": "anything"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "trustFlowId": ["The trust flow id field is prohibited."]
  },
  "transactionId": null,
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

trustFlowId and trustValidationId are prohibited on stateless endpoints. Sending either is a validation failure, not a silently ignored field.

Source unavailable

FAILED — Dukcapil source unavailable

Request

{
  "nik": "3171010101900029",
  "name": "BUDI SANTOSO",
  "dateOfBirth": "1990-01-01"
}

Response — HTTP 500

{
  "success": false,
  "code": "IDN_GOV_UNAVAILABLE",
  "message": "The Indonesian verification source is currently unavailable. Please try again later.",
  "verificationStatus": "FAILED",
  "verificationStatusCode": 6,
  "transactionId": "<uuid generated per request>",
  "verificationType": "dukcapil",
  "createdAt": "<UTC timestamp of the request>"
}

There is no data key at all. Branch on code, not on the presence of data. In live mode this failure is not billed.

Account-level responses

A missing or invalid Authorization header returns HTTP 401, and an account without the dukcapil plan returns HTTP 403 — both enforced in sandbox exactly as in live. See Sandbox introduction for their envelopes.

Stateless API Sandbox

Government Data

OCR

Verified

Review needed

Rejected

Validation failures

Source unavailable

Account-level responses

​Verified

​Review needed

​Rejected

​Validation failures

​Source unavailable

​Account-level responses

Verified

Review needed

Rejected

Validation failures

Source unavailable

Account-level responses