A company-contact export is easier to use when each address has an explicit purpose. A generic mailbox, a support address and an employee address are different kinds of evidence. Sending them all into one unqualified CRM email column makes later routing difficult to explain.
Company Contact Route Planner processes contact rows that have already been collected. It builds departmental route decisions for a company domain and requested purpose, using disclosed mailbox rules and fallbacks. A receiving operations workflow can preserve the reason a route was selected along with the source row that supplied it.
Begin with a small historical contact snapshot
This example is a shortened version of the installed public September snapshot. It records a generic mailbox found at that time. It is suitable for inspecting fallback behavior; it does not claim the address is currently monitored or authorize sending a message.
{
"items": [
{
"domain": "apify.com",
"emails": [
"hello@apify.com"
],
"checkedAt": "2026-09-22T05:45:22.120Z",
"found": true
}
],
"maxInputRows": 100,
"maxResults": 10,
"targetPurposes": [
"sales",
"general"
]
}
Restrict targetPurposes to the departments the workflow actually needs. The available purposes are sales, support, press, partnerships and general. Each domain-purpose combination is a separate route decision, so requesting all departments can produce several useful results from one source company.
Keep the match type beside the address
An exact role mailbox gets a different confidence label from a generic fallback. A phone or contact-page fallback requires manual research. Preserve routeType, action and confidence in the CRM staging table rather than retaining only routeValue.
Those labels describe how the source evidence matched the dictionary. They do not measure deliverability, response likelihood or commercial suitability. A high-confidence role match can still be an obsolete or unattended mailbox. The source observation date remains relevant when a person reviews the route.
Preserve the domain boundary
The transformation normalizes company hostnames and uses own-domain role-mailbox evidence. It also reports exclusion counts for relevant categories without emitting excluded address strings. This helps teams understand why a source row containing many addresses may yield only a small number of departmental routes.
If the source uses an unexpected corporate domain, review the company mapping before importing. A routing table should not silently merge organizations because their display names resemble each other. Keep the normalized domain as the company key and record any later account-resolution decision separately.
Use the table as a controlled handoff
Stage route records with their source and purpose. Ask the receiving team to confirm which actions its own process permits. A record marked manual_research should remain a research task until a person chooses and verifies an appropriate route.
Keep free diagnostics alongside useful routes. An invalid source domain, a failed collection row and a valid company with no supported route are distinct outcomes. Collapsing them into an empty address cell loses the information needed to repair the upstream export or decide that no useful departmental route is available.
For repeat imports, use a company-purpose key together with the source snapshot identity. Preserve prior accepted routing decisions until a newer record has passed review. The Actor performs each batch independently, so persistent deduplication and approval belong in the receiving workflow. This produces a contact table whose contents can be explained without implying that the transformation verified a mailbox or sent an email.
Price and verification scope
Listing pricing read on 23 October 2026 is $0.01 per result-found event on the FREE tier. The documented unit is: One useful contact route delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.
This article uses the installed source contract from build 0.1.7 (VP76cUbUHRKbzbcdl). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.
Inspect the Actor's current input and pricing.
AI-assisted draft; independent technical and cover review is required before publication.
Top comments (0)