VerificationQuestion Schema
Use verification questions to collect employer or institution responses beyond core verification fields (dates, title, degree, and similar). Define custom questions when you create an order; responses are returned on terminal webhooks after the verifier completes the form. Attach questions on each search viasearchTypes[].verificationQuestions. See SearchTypeDto.
Prerequisites
- Authentication — Bearer token required. See Authentication.
- Create order — Questions are sent in the Create order body under each
searchTypes[]entry. - Supported search types —
EMPLOYMENTandEDUCATIONonly.
Standard employment and education form fields are always prepended automatically. Custom questions follow in the order you send them.
Integration flow
Click the diagram to view full screen
- Define custom questions on each relevant
searchTypes[]entry at order creation. - The platform sends a form (PDF and/or online questionnaire link), including custom questions and standard questions.
- Responses are extracted from the returned form or eform payload.
- On
verification.completed, answers appear indata.verificationQuestions(anddata.questionnaire). Incomplete or invalid required answers escalate viaverification.action_requiredinstead — those paths do not also sendverification.completed.
Questions are defined at order creation only. You cannot add or change questions after the order is submitted.
Supported Fields (request)
Send these fields when creating an order. Do not sendfieldKey, origin, or conditionMet — the platform assigns those.
Validation limits
Invalid payloads return
400 Bad Request. See Error handling.
Question types
Type-specific rules
Conditional questions
Optionalcondition attaches a one-level dependency on an earlier question:
Allowed parent types:
yes_no, single_select, checkbox, numeric, rating_scale (not free_text or multi_select).
Nesting: One level only — a parent that itself has a condition is rejected.
Semantics after extraction:
- Parent matches →
conditionMet: true;requiredapplies if set. - Parent does not match →
conditionMet: false; childselectedAnsweris cleared tonull. Excess answers still allow completion when other required fields are satisfied.
Ordering and schema version
- Display order = array order of
verificationQuestionsin the request. - The resolved form is standard questions first, then custom questions in request order.
- Questionnaire instances use
schemaVersion"1".
Response fields (webhook)
Each question in webhook payloads includes the request fields plus:Where responses appear
Channel selection and escalations
Outbound does not branch on whether custom questions are required. Email and fax send a verification PDF in parallel when those channels are enabled. The email body includes the questionnaire URL when the search has a non-emptyquestionnaireUrl.
Incomplete or invalid answers
On PDF / fax / voice inbound paths (not host-validated eform):
These paths emit
verification.action_required with reasonCode: HUMAN_ESCALATION and do not emit verification.completed.
Online eform completeness for required questions depends on the eform host. Preferred structured payload shape:
Standard questions
The platform always prepends standard questions for the search type. StandardquestionId values live in a reserved range (700001+ employment, 700101+ education). Collision is keyed by (questionId, fieldKey) against the active standard set:
- Exact
questionId+fieldKeymatch → idempotent skip (custom copy ignored) - Same
questionId, differentfieldKey→400 Bad Request - Same
fieldKey, differentquestionId→400 Bad Request
700003 employment status, 700007 salary, 700101 graduated, 700107 gpa) are reusable as custom IDs. Standard question definitions cannot be overridden.
Employment (searchType: "EMPLOYMENT")
All employment standard questions are optional (required: false).
Education (searchType: "EDUCATION")
All education standard questions are optional (required: false) with allowComment: false.
Internal QuestionnaireInstance
The platform stores questions as aQuestionnaireInstance:
verification.completed, both are present when a questionnaire is pinned:
data.verificationQuestions— thequestionsarray (convenient flat access)data.questionnaire— the full instance (schemaVersion,searchType,questions)
Examples
Custom questions on order creation
Include aquestionnaireUrl when you have required custom questions and a usable email contact — that routes the verifier to your eform instead of a verification PDF.
condition.dependsOn: 700001 targets the standard employment eligible_for_rehire question. 100008 depends on a custom yes_no parent (100004).
Minimal optional questions (no eform required)
When every custom question is optional, channel selection stays on the standard parallel PDF path. You can omitquestionnaireUrl:
Webhook response (verification.completed)
Answers arrive on the completed webhook. data.verificationQuestions is the flat array; data.questionnaire wraps the same questions with schema metadata. Core verification results (verificationResult, employmentVerification / educationVerification) are unchanged — questions are additive.
In a live payload,
questionnaire.questions is the same array as data.verificationQuestions (shown abbreviated as [] above to keep the example readable).Parsing answers in your handler
Escalation: missing required answer
Escalation: invalid answer marks
Escalation: voice-only contact
HUMAN_ESCALATION events — alert ops, show escalationSubtype in review UI, and use partial metadata.verificationQuestions when present. See Webhook events.
Implementation notes
- Stable IDs — Reuse the same
questionIdacross orders for correlation. CustomfieldKeyis derived from the prompt; changing the prompt changesfieldKey. - Pre-fill — Set
selectedAnswer/commentat order creation when known. The verifier may still change values on the form. - Parsing — Index by
fieldKeyfor standard questions and byquestionIdorfieldKeyfor custom. Useoriginto distinguish them. Treatmulti_selectanswers as arrays. - No custom questions — Standard questions still appear on the form and in webhooks (
data.verificationQuestions/data.questionnaire). - Escape hatches — For required
free_text/numericthere is no built-in “unable to answer” path. Prefersingle_select/multi_selectwith anUnknown/N/Aoption when verifiers may not know the answer. - Eform preferred payload — When hosting your own questionnaire, post structured answers keyed by
fieldKey(see Incomplete or invalid answers). - Delivery — Question answers ride the same webhook delivery path as other terminal events (HMAC signature, retries, idempotency via
X-Event-Id). See Webhook integration.
Common integration pitfalls
FAQ
Are standard questions always included? Yes. Standard employment/education questions are always prepended — even when you send zero custom questions. Custom questions follow in request order. Can I update questions after creating an order? No. Define all questions in the initial Create order request. Questions are immutable after submit. Doesmulti_select break existing consumers?
Only for that type: selectedAnswer is a string[]. Other types remain strings (or null). Update consumers that assume every answer is a string.
When do I get data.questionnaire vs only data.verificationQuestions?
Both are present together whenever a questionnaire is pinned on the search (EMPLOYMENT and EDUCATION searches). Use whichever shape is more convenient; the question objects are identical.
Do questionnaire escalations also send verification.completed?
No. Gate escalations (MISSING_REQUIRED_INFORMATION, VERIFICATION_DATA_INVALID) and VOICE_ONLY_NOT_SUPPORTED emit verification.action_required only.
Related documentation
- SearchTypeDto — Where
verificationQuestionsattaches to each search - Create order — Full request body reference
- Webhook events —
verification.completedandverification.action_requiredpayload reference - Webhook integration — Delivery, signatures, retries, and handler examples
- Webhook overview — Lifecycle timing for question responses

