ListarProductsPricingToolsSign in

Enrich HubSpot or Salesforce with verified mobiles, natively

Updated

Yes, every new contact can be enriched with a verified mobile automatically, with no Zapier, no Make and no CSV export. Both HubSpot and Salesforce have a native mechanism for calling an external service when a record is created.

The reason most guides route you through Zapier is not technical. It is that the native route requires your data vendor to have built the integration on their side, and most have not. Zapier also has a flaw that rarely gets mentioned: it polls instead of receiving. On the free plan the interval is fifteen minutes.

The native routes, side by side

HubSpot Salesforce
Receive the creation event Webhooks API in a connected app, subscribed to object creation and property-change events. Available from the free tier Record-triggered Flow, after-save. Enterprise and Unlimited editions
Call an external service Custom workflow action supplied by the connected app. Workflows require Professional or above Asynchronous path in the Flow, which runs after the original transaction commits
Route without a dedicated app "Send a webhook" action, Data Hub Professional and Enterprise only HTTP Callout element in Flow, or an external service registered from an OpenAPI specification
Write the result back HubSpot CRM API Update Records element in the Flow

Two structural limits to know before designing anything.

In HubSpot, a workflow only triggers on an existing record. There is no native endpoint that accepts an external payload and creates a contact from scratch. If your need is to create the contact from an outside source, you post it to the CRM API first and let the workflow enrol on the record that was created.

In Salesforce, a before-save Flow cannot call an external service. It is up to ten times faster, which makes it tempting. An external callout requires an after-save Flow with an asynchronous path, which runs once the transaction has committed.

Why the native route beats Zapier

Three differences, and only one is usually cited.

Latency. Zapier polls your CRM at an interval to notice what is new: fifteen minutes on the free plan. HubSpot's Webhooks API and Salesforce's Flow push the event as it happens. For an inbound lead you intend to call within five minutes, that gap decides the outcome.

Hop count. Zapier puts a third party between your CRM and your data vendor, which means one more contract, one more point of failure, and one more copy of personal data to account for in your records of processing.

Cost at volume. Automation platforms bill per task. One enrichment per contact created becomes a cost line that grows with your activity, on top of the enrichment itself.

None of which makes Zapier a bad choice. If your vendor has not built a native integration, it is the only route there is and it works. Worth noting in fairness: the most-cited vendor on this question states on its own page that only the Zapier, Make or n8n route is genuinely automatic in its case, its other routes being manual.

The HubSpot build

What you need. A connected app on the vendor side, or failing that Data Hub Professional for the send-a-webhook action. Super Admin or Workflows permissions.

1. The event. Two options. Either the vendor subscribes through the Webhooks API to contact creation events, which works from the free tier and needs no workflow at all; or you build a workflow triggered on contact created and add the vendor's action to it, which requires Professional or above.

2. The enrolment condition. This is the step everyone skips and the one that costs the most. Do not enrol every contact created: enrol those with no mobile yet, inside your target, and not already attempted. We cover this in triggering enrichment without burning credits.

3. The enrichment action. It starts from what you already hold: first name, last name, company, and ideally a stable company identifier.

4. The write-back. The properties to write are not just the number, and this is where almost every integration on the market stops too early. The detail is in the CRM field schema.

Technical limits worth knowing: a custom code action has twenty seconds and can handle up to fifty properties. If your enrichment is slower than that, it has to be asynchronous: acknowledge immediately, write the result later.

The Salesforce build

What you need. Enterprise or Unlimited edition for record-triggered Flows, and Manage Flow permission.

1. The Flow. A record-triggered Flow on Contact or Lead, set to run when a record is created, after save.

2. The asynchronous path. Tick the option to include a run-asynchronously path to access an external system after the original transaction commits. This is not optional: without it the external callout is refused by transaction limits.

3. The invocable action. Three possible origins. A package installed from AppExchange that exposes your vendor's action. An external service registered from an OpenAPI specification, which Salesforce converts into invocable actions usable in Flow Builder without code. Or an HTTP Callout element directly in the Flow.

4. The update. An Update Records element writes the result back.

One thing to plan for: external actions do not automatically retry when the third-party service responds late. Retry logic is yours to build, and recording failures in a dedicated object so they can be replayed is the usual pattern.

What to ask your vendor

Six questions, and the first one separates the products immediately.

  1. Do you have a connected app in the HubSpot marketplace, or an AppExchange package, or do I build the integration myself?
  2. Is your enrichment synchronous, or do you answer later? If later, how does the result get back into the CRM?
  3. Which properties do you write back, exactly?
  4. Do you write a verification date and an attempt status, or only the number?
  5. Does syncing consume credits on records that are already enriched?
  6. Does my enrichment subscription cover CRM usage, or is that a separate subscription?

The sixth catches people out. At least one vendor bills its CRM integration separately, priced on the number of CRM records rather than in credits, and states that credits from the main subscription cannot be used to enrich the CRM. Confirm it before you build on it.

Where Listar sits

We expose an API and an MCP connector, which covers both routes above: the external callout from a Salesforce Flow, and the action triggered on the HubSpot side once the creation event reaches you.

What we deliver that matters for this page: line type with every number, a flag that says whether its attachment to the person is formally proven, and a company identifier resolved against official registers, which materially improves matching when your CRM record holds only a trade name.

A package exists for both HubSpot and Salesforce, and certification is in progress. What that means in practice, because the nuance matters: the native route described above works without you building the integration, and installation is by direct link. You will not yet find us by searching either marketplace, and we are not a certified app until certification is granted.

We write it out rather than abbreviating it, because the gap between "we have an API", "we have an installable package" and "we are a certified app" is exactly what the first question above is for. It should be put to us as to anyone else, and that is our answer.

FAQ

Can I enrich HubSpot automatically without Zapier? Yes. Two native routes exist: a vendor can subscribe to HubSpot's Webhooks API for contact creation events, which works from the free tier, or expose a custom workflow action you add to a workflow, which requires Professional or above.

Which HubSpot tier do I need? The Webhooks API works from the free tier, on the app side. Workflows require Professional or Enterprise. The "Send a webhook" action is Data Hub Professional and Enterprise only.

How do I do the same in Salesforce? A record-triggered Flow, after save, with an asynchronous path to allow the external callout, then an invocable action from an AppExchange package, from an external service registered via an OpenAPI specification, or an HTTP Callout element. Record-triggered Flows are available in Enterprise and Unlimited editions.

Why does a before-save Flow not work? Because it runs inside the save transaction and cannot call an external service. It is faster, up to ten times, but unsuitable for enrichment.

Is Zapier really worse? On three counts, yes: it polls rather than receives, at fifteen-minute intervals on the free plan; it adds an intermediary to account for in your records of processing; and it bills per task. If your vendor has no native integration, it is the only route available and it does work.

Should every new contact be enriched? No, and this is the most expensive mistake. The enrolment condition should exclude records that already hold a mobile, those outside your target, and those already attempted without result.

Sources

All guides

Listar AI