How to use a Righthand with Hunter

Quick answer

Use Righthand to prepare a Hunter email-research review for an authorized contact project. Preserve verification status and provenance without treating discoverability as permission to send.

Start with a reviewable deliverable, keeping Hunter as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

Hunter documents Domain Search, Email Finder, and Email Verifier API functions. See the official Hunter reference. Provider capabilities and Righthand's available tools are separate checks.

Use the permitted domain-search or verification output already supplied by the owner, with email, source, timestamp, and consent context. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: company domain, contact name, email, verification status, source URL, checked time. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A found or verified address does not establish outreach authorization or guarantee delivery. Keep sending outside the research brief.

Illustrative first-run brief

Use the owner-provided Hunter snapshot or approved read-only view. Review the supplied twenty-contact search results. Separate verified, uncertain, and unmatched addresses and retain source references. Do not send or enroll contacts. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the sales-operations owner to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

A missing address remains unknown; a catch-all or uncertain result stays in its own category rather than becoming safe to contact.

Compare a result with its provider status and intended company identity. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

A same-name person or changed domain can create a wrong match. Ask for identity confirmation and retain the unresolved row instead of guessing.

If verification status is missing or old, label it unknown and request current evidence before preparing any contact recommendation. Do not infer permission to send.

FAQ

What should the reviewer verify first?

Check the email address, company association, verification date, and source. A technically plausible or verified address does not establish consent or relevance.

How should a repeat run be scoped?

Preserve email IDs and verification timestamps across reviews. Recheck stale status before any separately authorized outreach and keep opt-out or contact restrictions attached.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.