Philippines PRC sandbox

Sandbox payloads for the Stateless PRC endpoint.

POST /api/v3/verifications/philippines/prc-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. PRC supports exactly one of two search modes per request:

Search mode	Fields
By license	`profession`, `dateOfBirth`, `licenseNo`
By name	`profession`, `firstName`, `lastName`

Every field must match a documented scenario exactly. Send dateOfBirth as YYYY-MM-DD: live accepts other date formats, but sandbox compares the value as sent, so 02/01/1990 does not match 1990-02-01 and is answered as a no-match.

Verified

VERIFIED — By license sample 1

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "1990-02-01",
  "licenseNo": "1234567"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "profession": "Mechanical Engineer",
    "birthdate": "02/01/1990",
    "fullName": "SANTOS, Jordon",
    "registrationDate": "June 01, 2022",
    "picture": "Qk06AAAAAAAAADYAAAAoAAAAAQAAAAEAAAABABgAAAAAAAQAAAATCwAAEwsAAAAAAAAAAAAA////AA==",
    "isValid": true,
    "licenseNumber": "1234567",
    "pictureValidity": "December 20, 2028"
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

birthdate is returned as MM/DD/YYYY, the format the PRC source uses, regardless of the YYYY-MM-DD you send.

VERIFIED — By license sample 2

Request

{
  "profession": "Registered Nurse",
  "dateOfBirth": "1992-08-15",
  "licenseNo": "0765432"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "profession": "Registered Nurse",
    "birthdate": "08/15/1992",
    "fullName": "DELA CRUZ, Maria Reyes",
    "registrationDate": "November 28, 2015",
    "picture": "Qk06AAAAAAAAADYAAAAoAAAAAQAAAAEAAAABABgAAAAAAAQAAAATCwAAEwsAAAAAAAAAAAAA////AA==",
    "isValid": true,
    "licenseNumber": "0765432",
    "pictureValidity": "August 15, 2027"
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

VERIFIED — By name

Request

{
  "profession": "Mechanical Engineer",
  "firstName": "Jordan",
  "lastName": "Santos"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "profession": "Mechanical Engineer",
    "firstName": "Jordan",
    "lastName": "Santos",
    "isValid": true
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

A by-name search confirms that a professional with this name is registered under the profession. It returns no license number, birthdate or picture — search by license when you need those.

VERIFIED — By name, compound surname

Request

{
  "profession": "Registered Nurse",
  "firstName": "Maria",
  "lastName": "Dela Cruz"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "profession": "Registered Nurse",
    "firstName": "Maria",
    "lastName": "Dela Cruz",
    "isValid": true
  },
  "verificationStatus": "VERIFIED",
  "verificationStatusCode": 3,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

Send multi-word surnames with their spaces, exactly as registered.

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 — By license, date of birth does not match

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "1991-02-01",
  "licenseNo": "1234567"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "isValid": false
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

The license number is the same one used in the first verified scenario. A wrong date of birth rejects the record and returns none of the holder’s details.

REJECTED — By license, license not found

Request

{
  "profession": "Civil Engineer",
  "dateOfBirth": "1988-05-20",
  "licenseNo": "0000005"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "isValid": false
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

A date-of-birth mismatch and a missing license return the same response. Your integration cannot tell them apart, and should not try to.

REJECTED — By name, not found

Request

{
  "profession": "Civil Engineer",
  "firstName": "Paolo",
  "lastName": "Garcia"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "isValid": false
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

REJECTED — Not found, unmatched payload fallback

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "1990-02-01",
  "licenseNo": "0000006"
}

Response — HTTP 200

{
  "success": true,
  "message": "Philippines PRC processed successfully",
  "data": {
    "isValid": false
  },
  "verificationStatus": "REJECTED",
  "verificationStatusCode": 1,
  "transactionId": "<uuid generated per request>",
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

This payload matches no documented scenario, so it takes the no-match fallback — identical to the rejections above apart from transactionId and metadata. Fire it once to confirm that an unknown record never reaches the live PRC source.

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 — Neither or both search modes sent

Request

{
  "profession": "Mechanical Engineer"
}

Response — HTTP 400

{
  "success": false,
  "code": "VALIDATION_FAILED",
  "message": "The request could not be validated. Please check the submitted fields.",
  "errors": {
    "search": ["Provide either dateOfBirth with licenseNo, or firstName with lastName."]
  },
  "transactionId": null,
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

Send exactly one search mode. Sending both — dateOfBirth and licenseNo together with firstName and lastName — returns the same error.

VALIDATION_FAILED — Profession missing

Request

{
  "dateOfBirth": "1990-02-01",
  "licenseNo": "1234567"
}

Response — HTTP 400

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

VALIDATION_FAILED — License number without date of birth

Request

{
  "profession": "Mechanical Engineer",
  "licenseNo": "1234567"
}

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 when license no is present."]
  },
  "transactionId": null,
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

The reverse also applies: dateOfBirth without licenseNo fails with "The license no field is required when date of birth is present."

VALIDATION_FAILED — First name without last name

Request

{
  "profession": "Mechanical Engineer",
  "firstName": "Jordan"
}

Response — HTTP 400

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

VALIDATION_FAILED — Date of birth not a valid date

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "notadate",
  "licenseNo": "1234567"
}

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 is not a valid date."]
  },
  "transactionId": null,
  "verificationType": "philippines_prc",
  "createdAt": "<UTC timestamp of the request>"
}

VALIDATION_FAILED — Trust flow fields sent to a stateless endpoint

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "1990-02-01",
  "licenseNo": "1234567",
  "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": "philippines_prc",
  "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

Each search mode has its own scenario. Both return the same response.

FAILED — PRC source unavailable, by license

Request

{
  "profession": "Mechanical Engineer",
  "dateOfBirth": "1990-02-01",
  "licenseNo": "0000009"
}

Response — HTTP 500

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

There is no data key at all. The envelope treats code and data as mutually exclusive, so a coded failure drops data rather than emitting an empty object. Branch on code, not on the presence of data.

FAILED — PRC source unavailable, by name

Request

{
  "profession": "Mechanical Engineer",
  "firstName": "Unavailable",
  "lastName": "Source"
}

Response — HTTP 500

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

Account-level responses

Two further responses are not specific to this endpoint. A missing or invalid Authorization header returns HTTP 401, and an account without the philippines_prc plan returns HTTP 403 — both enforced in sandbox exactly as in live. See Sandbox introduction for their envelopes.

Stateless API Sandbox

Australia DVS

Philippines Government

Document OCR

Verified

Rejected

Validation failures

Source unavailable

Account-level responses

​Verified

​Rejected

​Validation failures

​Source unavailable

​Account-level responses

Verified

Rejected

Validation failures

Source unavailable

Account-level responses