​

SNH AI Background Check API

Programmatic API for employment, education, and related verification workflows. Orders run asynchronously; your integration should create orders, poll search state (or rely on webhooks), and handle errors with retries where appropriate. The API is multi-tenant: your JWT must include the tenant claim SNH AI configures for your account.

​

Why SNH AI

• Automated contact discovery — AI research finds HR and registrar-facing contacts via web signals, geography, organization research, and scoring (no spreadsheets of phone numbers required).
• Multi-channel orchestration — Policies drive email → fax → voice fallbacks in production.
• Structured outcomes — Inbound payloads route through extraction so verification.completed closes with structured verification data.
• Async-first integration — Create orders immediately; track progress via webhooks and search polling (Webhook overview).

Start in sandbox with an SNH AI–issued token, then move the same payloads to production credentials.

​

How to integrate

1. Authentication — Bearer JWT on every call except GET /health; request sandbox credentials from SNH AI .
2. Quickstart — Health check, optional release-form upload, create one employment order, fetch order and searches, webhook outline.
3. Order lifecycle — Create an order, inspect searches, and handle webhooks.
4. Sandbox reference — Sandbox-specific limits before production.
5. Background Check overview — Stable vs placeholder endpoints, base URLs, OpenAPI note.
6. Orders — Create, Get, List searches, Get search.
7. Webhooks — Overview, Events, Integration (signatures, routing, idempotency).
8. Third-party ban — Configure searches so specific third-party vendors are not used.
9. Error handling — Status codes and validation payloads.

For request field details, use the Schemas section (VerificationRequest, Applicant, WebhookConfig).

​

Enterprise & production readiness

• Multi-tenant isolation — Every request is scoped to the tenant claim in your JWT; tokens never cross tenants. See Authentication.
• Asynchronous by design — Order creation returns immediately; searches complete later. Drive state from webhooks and verify the X-Webhook-Signature (HMAC-SHA256) before processing; use polling only as a fallback.
• Resilient integration — Retry transient 5xx/network errors with backoff, never 4xx, and treat order creation as non-idempotent — reconcile by externalSearchId rather than blindly resending. See Error handling.
• SLAs & escalation — Searches that can’t auto-complete are escalated and reassigned on tenant-configurable SLAs. See SLA and automatic reassignment.
• Batches are placeholder today — POST /batches creates orders but has no durable batch tracking; record each returned verificationOrderId. See Background Check overview.

​

Common client scenarios

See Integration patterns for short examples: employment-only, education-only, combined checks, skip-research with contact hints, third-party vendor bans, email-only channel policy, manual review, per-search webhook routing, release-form upload, batch create caveats, and webhook idempotency.

​

Support