Skip to main content

Examples

Download this guide

Each snippet focuses on the differing parts of a Create order request. Combine with full field requirements from Applicant, Business context, History, and Verification request.

Pattern index

Employment-only

Education-only

Employment and education on one order

(Include complete applicant and businessContext as for a single-type order.)

Known contacts / skip broad research

Use defaultSearchConfig or per-search searchConfig with research.skipResearch: true and seed outbound.contactHints. See Search config.

Ban third-party vendors

Use thirdPartyBan when a client does not want searches routed to specific third-party providers. Values are canonical vendor codes; see Third-party ban for the full supported list.

Ban multiple vendors order-wide

Ban wins over third-party deferral

When a banned vendor is detected, third-party routing is suppressed and manual/outbound handling continues.

Email-only outreach

Manual review (inbound)

Per-search webhook routing

Use WebhookTarget objects under closeoutEndpoints and fallbackEndpoint (string URL, single object, or array). Example: send employment closeouts to one URL and everything else to a fallback:

Release-form upload

Provide a signed release PDF in applicant.signedReleaseFileUrl using one of:
  • HTTPS URL — host the PDF at a stable public URL
  • GCS upload (recommended for larger files) — presigned upload flow below
  • Inline base64 — raw base64 or data:application/pdf;base64,... (max 10MB); uploaded to cloud storage at order creation

GCS upload flow

  1. GET /files/release-form/generate-upload-urlsignedUrl, fileUri
  2. PUT PDF to signedUrl with Content-Type: application/pdf
  3. Set applicant.signedReleaseFileUrl to fileUri (gs://...)
Generate upload URL · Signed release file

Batch create caveats

POST /background-check/v1/batches accepts { "orders": [ ...Verification request ] } and creates each order in parallel via the same path as single-order creation. The response includes a synthetic batchId and per-order verificationOrderId / searchIds in orders. Validation / creation errors: if any order fails validation or throws during createOrder, the whole HTTP request fails with an error (you do not get a 200 with mixed success/failure). Partial success risk: if the server fails after some orders were created (timeout, connection drop), you can be left with some orders already persisted. Persist every returned verificationOrderId as soon as you receive the response and reconcile with List orders. Order tracking: batch create returns per-order IDs only; track orders with List orders, Get order, and Get order searches.

Webhook idempotency

Deliveries may retry. Deduplicate with the X-Event-Id header (unique per delivery) and your own externalSearchId when you set it on searches. Acknowledge with a 2xx response; see Webhook events and Webhook integration.