Skip to main content

Third-party ban

Use searchConfig.thirdPartyBan when your organization does not want a search routed to specific third-party verification vendors. When a banned vendor is detected during research or inbound processing, SNH AI suppresses third-party routing for that vendor and continues with manual/outbound verification attempts.

When to use it

Request shape

Per-search searchConfig replaces defaultSearchConfig wholesale. If a search has its own searchConfig, include every search-level override that search needs inside that object.

Field rules

Supported vendor codes

These are the canonical values accepted by thirdPartyBan.

Employment

Education

UNKNOWN may appear in webhook metadata when a vendor could not be confidently recognized, but it is not accepted in thirdPartyBan.

Examples

Ban multiple vendors for all searches in an order

Combine ban with third-party deferral

If TALX_WORK_NUMBER is detected, the ban wins immediately. No pending third-party timer is created, and no delayed third-party webhook is emitted later.

Use a different third-party instead

Use this pattern when research or inbound might surface one third-party vendor, but your client requires verification through a different service. Ban the vendor you do not want; seed the vendor you do want as a contact hint.
thirdPartyBan and contactHints[].thirdPartyVendor must refer to different vendor codes. The API rejects a hint whose thirdPartyVendor also appears in thirdPartyBan for the same search — you cannot ban and seed the same vendor in one config.
Employment example: block The Work Number if research finds it, but route through Truework with a known employer code.
Education example: block National Student Clearinghouse if it appears, but use Parchment with a school identifier.
Hints-only (no research): when the client supplies the vendor up front and you do not want automated contact research to run.
At runtime:
  • If research or inbound detects a banned vendor, that vendor does not get third-party routing or a THIRD_PARTY_RECORD webhook; the search can still proceed on other contacts or on your hinted vendor.
  • The hinted vendor is merged into the contact plan per history item (deduplicated by vendor code and thirdPartyCode). It follows normal third-party precedence unless you set escalation.disableThirdPartyEvent: true to prefer direct channels on the same hint.
  • You may add email, phone, or fax on the same hint as a direct fallback alongside thirdPartyVendor.
For field-level rules on thirdPartyVendor and thirdPartyCode, see Search-level configuration and Search config.

Normalization and deduping

This resolves to ["TALX_WORK_NUMBER", "NSCH"].

Runtime behavior

Webhook expectations

When a vendor is banned, clients should not expect a THIRD_PARTY_RECORD action-required event for that vendor. For inbound redirects to a banned vendor, handle the human escalation event:

Validation failures

Invalid ban lists are rejected when the order is created.