Manage Search Contacts
Use these endpoints to inspect or change verification contacts after an order has been created. All five operations are scoped to a search within an order.Contact mutations are allowed only when the search is in
IN_PROGRESS or COMPLETED status.Successful mutations emit a
verification.notification webhook with notificationType set to
CONTACT_PLAN_ADDED, CONTACT_PLAN_UPDATED, CONTACT_PLAN_REMOVED, CONTACT_PLAN_MARKED_ACCURATE, or
CONTACT_PLAN_MARKED_INACCURATE. Notifications include metadata.contactId and, when available,
metadata.contactName. Accuracy notifications also include metadata.accuracyStatus and metadata.reason.Shared Path Parameters
The following path parameters apply to every operation on this page.Verification order ID (UUID).
Search ID (UUID) within the order.
Get Contacts
Returns the persisted contacts for a search, including removed contacts when present.This operation is read-only and does not emit a
CONTACT_PLAN notification or any other webhook event.Response
Contact records in the persisted contact plan, including removed contacts when present.
Parent-organization research metadata when available.
Example Request
Example Response
Add Contact
Adds a contact to the active contact plan.Request Body
Contact or department name.
Organization associated with the contact.
One or more contact method objects. Each method may include
email, phone, or fax, and must include confidence and
source.Contact’s job title or role.
Overall confidence score from
0 to 1.Contact location.
When
true, queues outbound attempts for the newly added contact immediately.Response
true when the contact-plan mutation notification was queued for delivery.Example Request
Example Response
Update Contact
Replaces the editable fields for an existing contact.Request Body
Contact ID returned by the contact plan or add contact response.
Contact or department name.
Organization associated with the contact.
Replacement contact methods for this contact. Pending scheduled attempts are cancelled or retargeted when destinations change.
Overall confidence score from
0 to 1.Contact location.
Optional replacement metadata for this contact. Because this endpoint uses
PUT, metadata from the previous contact is not
preserved unless you include it in this object. By default the API stores source: "manual_client_entry" and reason: "Manually update contact using endpoint", then stamps lastEditedBy and lastEditedAt.Response
Example Request
Example Response
Mark Contact Accuracy
Records audit feedback about whether a contact is accurate. Marking a contact inaccurate can cancel pending scheduled attempts for that contact. Marking a contact accurate can optionally queue outbound attempts. Successful requests emitCONTACT_PLAN_MARKED_ACCURATE or CONTACT_PLAN_MARKED_INACCURATE.
Request Body
Contact ID returned by the contact plan, add contact response, or get contacts response.
ACCURATE or INACCURATE.Non-empty reason for marking the contact accurate or inaccurate. Maximum length is 2000 characters.
Defaults to
true when accuracyStatus is INACCURATE. Cancels future scheduled attempts for the contact.Defaults to
false when accuracyStatus is ACCURATE. When true, queues outbound attempts for the contact.Response
Present when
executeOutboundAttempts is requested for an accurate contact.Present when
executeOutboundAttempts is requested for an accurate contact.Example Request
Example Response
Remove Contact
Removes a contact from the active contact plan.Request Body
Contact ID to remove from the active contact plan.
Reason stored in the contact audit history.
Defaults to
true. Cancels pending outbound work for the removed contact.Response
Example Request
Example Response
Webhook Behavior
Successful mutations emit the contact plan using the existingverification.notification event. For add, update, and mark accuracy operations, contactPlan contains the active plan after the mutation. For remove operations, contactPlan contains the removed contact snapshot so consumers can see which contact was deleted even when the active plan is now empty.

