Most Google Maps scraper APIs return raw extraction name, address, phone, done. If you're piping healthcare leads into a CRM, an outreach tool, or an internal dashboard, raw extraction was never really the hard part. Google Maps already exposes this information to anyone browsing directly; the actual engineering problem is prioritization deciding, programmatically, which of a few hundred results are actually worth acting on.
This actor's API returns a calculated lead score and a has Website boolean alongside the standard fields, so your integration doesn't have to build a scoring layer on top of the raw data afterward. This post covers the API surface, two working integration examples, and a few of the edge cases worth handling before you wire this into production.
Authentication and starting a run
Like any Apify actor, this runs through the standard Apify REST API you'll need an API token from your Apify account, available under Settings → Integrations. Runs are started with a POST request against the actor's runs endpoint, with your search parameters passed as the JSON body.
Starting a run Python
import requests
api_token = 'YOUR_APIFY_API_TOKEN'
actor_id = 'techforce.global~google-maps-healthcare-leads-sales-intelligence-tool'
response = requests.post(
f'https://api.apify.com/v2/acts/{actor_id}/runs',
headers={'Authorization': f'Bearer {api_token}'},
json={
'category': 'Dental Practices',
'location': 'Miami, FL',
'websiteFilter': 'No Website Only'
}
)
run_id = response.json()['data']['id']
dataset_id = response.json()['data']['defaultDatasetId']
print(f'Run started: {run_id}')
Fetching results once the run completes
Runs are asynchronous starting one returns immediately, but the actual scraping happens over the next several minutes depending on result volume. Poll the run status endpoint until it reports SUCCEEDED, then fetch the dataset items.
import time
def wait_for_run(run_id, token):
while True:
status = requests.get(
f'https://api.apify.com/v2/actor-runs/{run_id}',
params={'token': token}
).json()['data']['status']
if status == 'SUCCEEDED':
return True
if status in ('FAILED', 'ABORTED', 'TIMED-OUT'):
return False
time.sleep(5)
wait_for_run(run_id, api_token)
leads = requests.get(
f'https://api.apify.com/v2/datasets/{dataset_id}/items',
params={'token': api_token}
).json()
top_leads = sorted(leads, key=lambda x: x['leadScore'], reverse=True)
print(top_leads[:10])
Pushing top leads to a CRM webhook Node.js
The official apify-client package handles run polling internally, which simplifies the same workflow considerably in a Node environment
const { ApifyClient } = require('apify-client');
const client = new ApifyClient({ token: 'YOUR_APIFY_TOKEN' });
const run = await client.actor(
'techforce.global/google-maps-healthcare-leads-sales-intelligence-tool'
).call({
category: 'Clinics & Medical Centers',
location: 'Chicago, IL',
websiteFilter: 'No Website Only'
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
const topLeads = items.filter(l => l.leadScore >= 70);
await fetch('https://your-crm.example.com/webhook/leads', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(topLeads)
});
Understanding the input schema
The actor accepts five parameters, all optional except category and location for a meaningful search. Omitting category returns results across all eight healthcare types for the given location, which is useful for broad market-density research but less useful for targeted outbound prospecting, where narrowing to a single category up front keeps the result set relevant.
Understanding the output schema
The consistent use of 'N/A' rather than null or an empty string across every field is a deliberate choice it means your integration code can treat every field as a non-null string without defensive null-checking on each one individually, which simplifies downstream processing meaningfully once you're handling thousands of records rather than a handful in a manual test.
Handling rate limits and large result sets
For high-volume territories, results are paginated at the dataset level — use the standard Apify offset and limit query parameters when fetching items rather than assuming a single request returns everything. If you're running this across many cities on a schedule, staggering run start times rather than firing them all simultaneously avoids hitting your account's concurrent-run limit, which varies by Apify plan tier.
A note on error handling
Runs can fail for reasons unrelated to your integration code — a temporary Google Maps rate limit, an unusually specific location string with no matching results, or a transient network issue on Apify's infrastructure. Checking for a FAILED or ABORTED status explicitly, rather than assuming every run reaches SUCCEEDED, is worth building in from the start rather than retrofitting after a silent failure goes unnoticed in production.
Common integration patterns
Three patterns cover most real-world usage. The first is a one-off manual pull a sales rep or analyst triggers a run through the Apify Console directly, downloads the dataset as CSV, and imports it into whatever tool they're already using. No code required, and the fastest path for a single territory.
The second is a scheduled batch pull a cron job or n8n workflow triggers a run per territory on a recurring basis (weekly or monthly is typical), fetches results once each completes, and pushes new or changed records into a CRM automatically. This is the pattern that scales past a handful of territories without someone manually re-running searches.
The third is an on-demand API call triggered from inside another application for instance, a custom internal tool where a user picks a city and category from a dropdown, the tool calls this actor's API in the background, and results populate directly in the requesting application's own interface. This pattern requires the most integration work up front but produces the smoothest experience for end users who never need to know Apify is involved at all.
Why the lead score matters for API consumers specifically
If you're integrating this into an automated pipeline rather than reviewing results manually, the lead Score and has Website fields are what make automation actually useful rather than just faster. Without them, an automated pipeline would need to push every single result into a CRM or outreach tool indiscriminately, forcing a human to do the prioritization downstream anyway. With them, you can filter server-side pushing only leads above a chosen score threshold, or only no-website leads and let the pipeline do the triage that would otherwise require manual review.
Frequently asked questions
Does the API support server-side filtering by lead score?
Filtering happens client-side after fetching results, as shown in the examples above the API returns the complete scored dataset per run, and threshold filtering is applied in your own code.
What's the typical run time for a single city/category search?
This varies with result volume, but most single-city searches complete within a few minutes. Larger metro areas with broad categories can take longer, proportional to the number of listings being scored.
Can I run this on a schedule without manual intervention?
Yes, wrap either example above in a cron job, an n8n scheduled workflow, or a cloud function trigger, and the entire flow from run start to CRM push runs unattended.
Is there a sandbox or test mode for development?
Running with a very specific, narrow location (a small town rather than a major metro area) is the practical equivalent it returns real data but a small enough result set to test integration logic without burning through your per-result budget.
What happens if I pass an invalid category string?
The actor validates against the eight fixed categories and returns a clear input validation error rather than silently falling back to an unfiltered search worth handling explicitly in your integration so a typo in a category string fails loudly during testing rather than quietly returning unexpected results in production.
Can results be deduplicated across multiple runs for the same territory?
Deduplication isn't handled automatically at the actor level, since each run is independent if you're running the same territory repeatedly on a schedule, deduplicating on business name and address in your own pipeline before pushing to a CRM avoids creating duplicate records for practices that haven't changed between runs.
Getting started
Full actor documentation and the input schema reference are available on the Apify listing: apify.com/techforce.global/google-maps-healthcare-leads-sales-intelligence-tool. Pricing is pay per result, so testing an integration against a small location costs only what that test run actually returns.
Website : https://techforceglobal.com/
Top comments (0)