Webhook System Overview
The SNH AI webhook system provides real-time notifications throughout the verification lifecycle. This guide explains how webhooks fit into the overall verification workflow and when different webhook events are triggered.Verification Lifecycle
The verification workflow consists of several phases, each triggering specific webhook events:Webhook Event Types
SNH AI sends three types of webhook events:1. verification.completed
When it’s sent:- Verification reaches a terminal outcome (VERIFIED, NO_RECORD, WRONG_ORG, THIRD_PARTY)
- All verification data has been processed and validated
- Results are ready for consumption by your system
- Complete verification result with all extracted data
- Full employment or education verification object (provided vs verified fields)
- Discrepancy flag indicating if verified data differs from provided data
- Research decision log (audit trail of contact discovery)
- Education accreditation data (for EDUCATION searches)
- Terminal channel used (EMAIL, VOICE, or FAX)
- Update your applicant records with verified data
- Mark verifications as complete in your system
- Trigger downstream workflows (e.g., send results to hiring manager)
- Generate reports or analytics
2. verification.action_required
When it’s sent:- Verification cannot proceed without manual intervention
- Third-party vendor is required (
THIRD_PARTY_RECORD) - International education third-party detection (
INTERNATIONAL_EDUCATION) - External service failure (
UPSTREAM_ISSUE) - Internal system error (
SYSTEM_FAILURE) - SLA timeout exceeded (
SLA_REACHED) - All automation exhausted (
HUMAN_ESCALATION)
- Reason code explaining why action is required
- Structured contact payload for employment or education searches
- Metadata with troubleshooting context
- Research decision log (for
HUMAN_ESCALATION) - Contact plan data (when escalating with research results)
- Alert your team or end-user about the issue
- Route to appropriate handler based on reason code
- Guide users to next steps (e.g., submit via third-party portal)
- Track verifications requiring intervention
3. verification.notification
When it’s sent:- Intermediate stages during the verification process
- Research completes and generates a contact plan
- Outbound attempt is made (email sent, call initiated, fax dispatched)
- Inbound response received (email reply, voicemail, fax received, or JSON submission)
- Notification type (
CONTACT_PLAN,OUTBOUND_ATTEMPT,INBOUND_MESSAGE,INBOUND_RECEIVED_DETAIL) - Contact plan with discovered contacts and confidence scores
- Outbound attempt metadata (channel, destination, attempt number)
- Inbound message classification and summary
- Update UI in real-time with verification progress
- Show contact attempts to end users
- Track verification velocity and bottlenecks
- Log activity for compliance and audit purposes
Webhook Configuration
Webhooks can be configured at two levels:Organization-level Configuration
Global webhook settings for your organization, stored in your organization configuration. Contact your SNH AI account manager to configure organization-level webhooks. Benefits:- Applies to all verifications automatically
- Centralized management
- No per-request configuration needed
Request-Level Configuration
Per-verification webhook settings via thewebhookConfig object in the order creation request.
Benefits:
- Override organization defaults for specific orders
- Route different verification types to different endpoints
- Apply custom headers or authentication per order
closeoutEndpoints can be a string URL (legacy), one WebhookTarget object, or an array of URLs/objects. fallbackEndpoint accepts the same shapes.
Webhook Routing
Organization-level and request-level webhook config are merged field by field — providing a request-level target for one search type doesn’t suppress the organization’s config for a different search type, and type-specific and fallback targets aren’t exclusive tiers (both can receive an event concurrently if they match its filters). For the full merge and resolution behavior, see the canonical guide: Webhook Integration — Endpoint Resolution.Security, retries, and delivery
Webhooks are signed with HMAC-SHA256 (X-Webhook-Signature), identified for idempotency with X-Event-Id, and retried on transient failures. For signature verification code, header tables, retry/backoff rules, and handler best practices, see the canonical guide: Webhook Integration.
Research Decision Log
For verifications that complete research (contact discovery), webhooks include aresearchDecisionLog object that provides full transparency into how contacts were found:
Education Accreditation
For EDUCATION searches, completed and action_required webhooks include accreditation data:- Looks up institutions in the DAPIP (Database of Accredited Postsecondary Institutions) database
- Checks accreditation status at the reference date (graduation or attendance)
- Provides campus details, accreditor information, and historical timeline
- Suggests alternate campuses when exact match is not found
Next Steps
- Webhook Integration — signatures, retries, handlers, and testing
- Webhook Events — payload structures and field reference
- Error handling — API and delivery failure guidance