Webhook Events
SNH AI delivers webhook events to notify your application about verification status changes in real-time. This document provides comprehensive documentation of all event types, payload structures, field definitions, and examples from the actual verification system.Payload Structure
All webhook events follow a consistent structure with three top-level fields:Top-Level Fields
Payload Enrichment
The system automatically enriches webhook payloads with additional context: For all events withsearchId:
externalSearchId: Your external identifier provided at order creationresearchDecisionLog: Audit trail of contact discovery and research decisions
verification.completed, verification.action_required):
channel: Single terminal channel used (EMAIL, VOICE, or FAX)- Full verification object with provided vs verified fields
discrepancy: Boolean flag for VERIFIED outcomes when provided data differs from verified data
accreditation: Institutional accreditation status from DAPIP database- Includes campus details, accreditor information, and historical timeline
WebhookEventType Enum
HTTP Headers
Every webhook request includes these headers:Signature Verification
Webhooks are signed with HMAC-SHA256 (X-Webhook-Signature: sha256=<hex>). Always verify using the raw request body bytes. Full verification examples (Node.js, Python, OpenSSL) live in Webhook Integration.
Common Enums
SearchType
VerificationChannel
StandardOutcomeCode
Event: verification.completed
Sent when a verification search completes with results.Data Fields
VerificationResult Object
VerifierProfile Object
ResearchDecisionLog Object
Audit trail of research decisions made during contact discovery. Provides transparency into which sources were searched, why certain decisions were made, and the reasoning behind the final contact plan.ResearchDecision Object
Research Stages
Example: Research Decision Log
Understanding Provided vs Verified Fields
The verification system tracks two sets of data for each verification: Provided Fields (provided*):
- Information submitted by the applicant or requester at order creation
- Stored in the search metadata from the original request
- Used as the basis for verification and comparison
- Never modified during the verification process
verified*):
- Information confirmed through the verification process
- Extracted from employer/institution responses (email, voice, fax)
- Represents the ground truth according to the verifying organization
- May differ from provided fields (discrepancies)
discrepancy boolean:
false: All key fields match between provided and verified datatrue: One or more key fields differ (e.g., different job title, dates, location)
- Minor differences in how information is recorded (e.g., “Software Engineer” vs “Sr. Software Engineer”)
- Applicant inaccuracies (intentional or unintentional)
- Incomplete or outdated information from either source
- Data entry errors on either side
EmploymentVerification Object
Complete employment verification data with provided (claimed) and verified fields.Provided Fields (from applicant/requester)
Verified Fields (from verification)
Example: Employment Verification (Email)
Example: Employment Verification (Voice)
EducationVerification Object
Complete education verification data with provided and verified fields.Provided Fields
Verified Fields
Example: Education Verification (Fax)
Example: Education Verification (No Record)
AccreditationResult Object
Included in education verification webhooks (verification.completed and verification.action_required).
AccreditationReference Object
AccreditationMatch Object
CampusSummary Object
AccreditationEvaluation Object
AccreditationMetadata Object
AccreditationStatus Enum
Event: verification.action_required
Sent when verification cannot proceed without manual intervention.Data Fields
ActionRequiredReasonCode Enum
If
searchConfig.thirdPartyBan contains the detected canonical vendor, THIRD_PARTY_RECORD is intentionally suppressed. Research records an audit notation and continues manual/outbound handling. Inbound third-party redirects to a banned vendor emit HUMAN_ESCALATION with metadata.escalationSubtype: "THIRD_PARTY_BAN". See Third-party ban.ContactPayload Object
Structured contact information based on search type.EmploymentContactPayload
EducationContactPayload
Example: THIRD_PARTY_RECORD (Employment)
Example: THIRD_PARTY_RECORD (Education with Accreditation)
Example: UPSTREAM_ISSUE
Example: SYSTEM_FAILURE
Example: SLA_REACHED
Example: HUMAN_ESCALATION
Example: OTHER
Event: verification.notification
Sent during intermediate stages of verification process.Data Fields
VerificationNotificationType Enum
Classification Object
ContactPlanEntry Object
Understanding Confidence Scores:
Confidence scores (0-1) indicate the system’s trust in the contact information:
0.9-1.0: High confidence - Previously verified contacts, organization preferences with strict language0.7-0.89: Medium-high confidence - Verified contacts without strict language, internal database matches0.5-0.69: Medium confidence - Web research results, parent organization contacts< 0.5: Lower confidence - Uncertain matches, limited informationnull: No confidence score available (third-party vendors, manual entries)
- Determine outbound attempt priority (higher confidence contacts attempted first)
- Apply minimum confidence thresholds per channel (configurable in organization policy)
- Filter out low-quality contacts before outbound attempts
OutboundAttempt Object
InboundMetadata Object
Example: CONTACT_PLAN
Example: OUTBOUND_ATTEMPT
Example: INBOUND_MESSAGE (Email)
Example: INBOUND_MESSAGE (Voice)
Example: INBOUND_MESSAGE (Urgent)
Third-Party Vendor Reference
WhenreasonCode is THIRD_PARTY_RECORD, the metadata object includes vendor information. These same canonical vendor codes are accepted by searchConfig.thirdPartyBan for per-search third-party suppression; UNKNOWN is not accepted in the ban list. See Third-party ban for client-facing examples.
Employment Vendors
Education Vendors
Delivery, retries, and testing
Retry policy, signature verification handlers, idempotency, and local testing tools (ngrok, webhook.site) are documented once in Webhook Integration. Organization-level webhook defaults: Webhook Integration — Organization-level configuration. SLA and escalation behavior: SLA and escalation.Footnotes
- “Theary” is the product/platform name reflected in this wire-level identifier. It refers to the same product as “SNH AI,” the company name used elsewhere in these docs. ↩