Skip to main content

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 with searchId:
  • externalSearchId: Your external identifier provided at order creation
  • researchDecisionLog: Audit trail of contact discovery and research decisions
For terminal events (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
For EDUCATION searches:
  • 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 Fields (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 Detection: For VERIFIED outcomes, the system automatically compares key fields and sets the discrepancy boolean:
  • false: All key fields match between provided and verified data
  • true: One or more key fields differ (e.g., different job title, dates, location)
The comparison uses normalized values (case-insensitive, whitespace-trimmed, date formats normalized) to avoid false positives from formatting differences. Why This Matters: Discrepancies may indicate:
  • 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
Your system should review discrepancies and decide how to handle them based on your business rules.

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 language
  • 0.7-0.89: Medium-high confidence - Verified contacts without strict language, internal database matches
  • 0.5-0.69: Medium confidence - Web research results, parent organization contacts
  • < 0.5: Lower confidence - Uncertain matches, limited information
  • null: No confidence score available (third-party vendors, manual entries)
The system uses confidence scores to:
  • 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

When reasonCode 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

  1. “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.