Skip to main content

Search config

Search config captures per-search policy overrides. Omitted fields fall back to organization policy, then system defaults. All top-level sections are optional, with one conditional requirement: research.skipResearch=true requires at least one outbound.contactHints[] entry with email, phone, fax, or a thirdPartyVendor. It can be supplied in two places on a create-order request:
  • searchTypes[i].searchConfig — per-search overrides. When present (even as an empty {}), it fully replaces any request-level defaultSearchConfig for that search.
  • defaultSearchConfig — order-level default applied to every created search whose per-search searchConfig is absent.
Merge semantics are whole-object replace, not section-wise merge. If you set searchTypes[0].searchConfig = { channels: { email: true } }, only the channels override is applied for that search; timing, outbound, etc. revert to organization/system defaults — they are not inherited from defaultSearchConfig.

Fields

Most integrations only need one or two sections at a time. The tables below list every supported field by level so you can scan the shape first, then jump to examples.

Top-level searchConfig

channels

timing

timing.businessHours

outbound

outbound.contactHints[]

When research.skipResearch=true, contactHints are the sole outbound seed and the research agent is not invoked. When research.skipResearch=false, hints are merged on top of researched contacts per history item and deduplicated by normalized destination. Third-party hints are deduplicated against researched contacts (and one another) by canonical vendor code and thirdPartyCode. By default a third-party contact takes precedence over direct outbound and cancels remaining attempts; use escalation.disableThirdPartyEvent to fall through to any direct destinations on the hint.

research

inbound

Data-model implication when inbound is held for QA.When requireManualReview=true or autoCompleteOnVerification=false routes a verified inbound to QA, the persisted VerificationResult.outcome is set to ACTION_REQUIREDnot the extracted terminal outcome (VERIFIED, NO_RECORD, etc.). The extracted outcome is preserved in the activity/metadata trail for reviewers, but downstream consumers that read VerificationResult.outcome before QA resolution will see ACTION_REQUIRED. Once QA completes the manual review path, the outcome is updated to reflect the final decision.If your integration assumes VerificationResult.outcome always mirrors the inbound response, either leave autoCompleteOnVerification=true or wait for the subsequent verification.completed event before reading the outcome.

escalation

notifications

notifications.webhookOverride summary

qaDestinations

Non-production only. Values are accepted and validated in every environment, but applied only outside production. In production the real, researched contact destinations are always used and these values are ignored (a server-side warning is logged).
Precedence (non-production): search-level qaDestinations → organization policy QA destination → service default. Omitted channels fall back down that same chain.

Examples

Ban One Third-Party Vendor

Ban Multiple Third-Party Vendors

Ban Vendors With Normalization

The API trims whitespace, uppercases values, and deduplicates before policy resolution. This request resolves to ["TALX_WORK_NUMBER", "NSCH"].

Ban Third Parties While Deferral Is Enabled

thirdPartyBan wins over outbound.thirdPartyDeferral. If TALX_WORK_NUMBER is detected, no pending third-party timer is created and no delayed third-party webhook is emitted.

Email-Only Outbound With a Blocked Generic Inbox

Weekday 9-5 Central With a 48-Hour SLA

Attempt Caps Plus Multiple Pre-Known Contacts

Skip Research and Use Only Provided Contacts

Route Every Verified Inbound To QA

Email-Only Outbound Even When Any Third Party Is Detected

Use escalation.disableThirdPartyEvent when the search should suppress every third-party event, regardless of vendor. Use thirdPartyBan when suppression should apply only to specific vendor codes.

Per-Search Webhook Override That Only Routes Completions

Redirect Outbound to a QA Destination (Non-Production Only)

Omitted channels (here, fax) fall back to the organization-level QA destination, then the service default. This has no effect in production.

Example

A search config combining most sections, as you might attach to a single search:
Attached to a create-order request either as a per-search override or an order-level default:
In this request:
  • The EMPLOYMENT search gets its per-search overrides — defaultSearchConfig is not merged in (e.g. outboundWindowMinutes falls back to organization policy, not to 120).
  • The EDUCATION search has no per-search searchConfig, so it uses defaultSearchConfig (outboundWindowMinutes: 120 on top of organization policy).

Validation rules

  • channels.blockedDestinations and channels.allowedDestinations are mutually exclusive; each is capped at 100 entries.
  • Each outbound.contactHints[] entry must include at least one of email, phone, or fax, or a thirdPartyVendor; max 50 hints.
  • contactHints[].thirdPartyVendor must be a canonical vendor code or UNKNOWN; unknown codes are rejected. thirdPartyCode requires thirdPartyVendor, and a hint’s thirdPartyVendor cannot also appear in thirdPartyBan.
  • timing.businessHours.startTime must be strictly earlier than timing.businessHours.endTime; allowedDays values must be in 0–6.
  • timing.businessHours.timezone must be a valid IANA timezone (validated via Intl.DateTimeFormat).
  • inbound.requireManualReview: true combined with inbound.autoCompleteOnVerification: false is rejected at validation time — omit autoCompleteOnVerification or set it to true.
  • escalation.escalationWebhookUrl and any URL fields inside notifications.webhookOverride are validated as URLs.
  • research.skipResearch: true requires outbound.contactHints with at least one reachable contact (email, phone, fax, or a thirdPartyVendor) and bypasses the research agent at runtime. Channel-disabled contact methods are auto-suppressed; third-party hints route outside the channel pipeline and are never channel-suppressed.
  • thirdPartyBan must be an array of canonical third-party vendor codes. UNKNOWN, malformed values, non-arrays, and unknown codes are rejected. Empty arrays are accepted and behave the same as omission.
  • qaDestinations is accepted and validated in every environment, but only applied outside production; in production it is dropped during policy resolution (a warning is logged) and never reaches outbound.
  • Unknown fields on searchConfig are not part of the public contract and may be ignored by runtime policy resolution; send only the fields documented above.

Behavior precedence

Once a search is created, the runtime resolves its effective policy by layering organization defaults under the per-search overrides. These precedence rules apply at runtime:
  • Escalation gating: escalation.disableAutoEscalation=true wins over organization-level humanEscalation.enabledForSource. When disableAutoEscalation=false (or omitted), the per-source organization flag is consulted.
  • Escalation webhook routing: notifications.webhookOverride > escalation.escalationWebhookUrl > organization webhook config. Set one or the other, not both.
  • Inbound terminal routing: inbound.requireManualReview=true routes verified inbounds to ACTION_REQUIRED regardless of autoCompleteOnVerification. When requireManualReview=false, autoCompleteOnVerification=false holds the search for QA as ACTION_REQUIRED; autoCompleteOnVerification=true (default) auto-completes.
  • Outbound cancel on terminal inbound: a pending third-party task always cancels outbound, regardless of outbound.cancelOutboundOnTerminalInbound.
  • Third-party ban: thirdPartyBan wins over immediate third-party routing, third-party deferral, and inbound third-party redirects for matching canonical vendors. Banned vendors may still appear in the contact plan for auditability, but third-party webhooks are not emitted.
  • Organization preferences: applied after per-search channel overrides. An org-level channel block still suppresses a channel that searchConfig.channels.* enables — this is a safety rail.
  • Notification suppression: notifications.suppressNotifications only affects intermediate verification.notification events. Terminal verification.completed and verification.action_required always fire.
  • Raw inbound stripping: only applied when notifications.includeRawInboundInWebhook is explicitly false. Tenants that have not set the flag retain current behavior.

Merge semantics

  • When searchTypes[i].searchConfig is undefined or null, defaultSearchConfig applies for that search.
  • When searchTypes[i].searchConfig is present — including {} — it fully replaces defaultSearchConfig for that search. Section-wise merging is not performed.