Disclosure: I run basedonb, the Google Maps lead API in this scenario. The pipeline pattern works just as well with Outscraper, Apify, or anything else that returns business leads as JSON.

I run a one-person agency on the side. Every Monday at 9 AM I want a fresh list of N businesses in a target city, deduped against what's already in HubSpot, with new contacts slacked to me before standup. I used to do this manually on Sunday nights. This post is the Make.com scenario that replaced 30 minutes of CSV gymnastics with zero touches.

The whole thing is one scenario, six modules, ~$0.05 per run.

What we're building

[Cron: Monday 9am]
       │
       ▼
[HTTP — POST basedonb /scrapes]
       │
       ▼
[Iterator — split results array]
       │
       ▼
[HubSpot — search contact by phone]
       │
       ▼
[Router — exists? skip : create]
       │
       ▼
[Aggregator — count new]
       │
       ▼
[Slack — post summary]

Output: a Slack message that says "27 new dentists in Manhattan added to HubSpot this morning" with a link to the segment.

Stack

• basedonb — lead source (REST API). docs.
• Make.com — orchestration. Free plan covers ~1,000 ops/mo, enough for weekly runs at modest volume. There's also a native basedonb integration page that walks through the connection.
• HubSpot — CRM destination. Free tier works.
• Slack — heartbeat + summary.

If you prefer Zapier, the same shape works there — basedonb has a Zapier integration too. I picked Make because the Iterator/Router primitives map cleanly to "split the array, branch per item."

Step 1 — the HTTP module (basedonb scrape)

Make.com → "HTTP" → "Make a request":

• URL: https://www.basedonb.com/api/v1/scrapes
• Method: POST
• Headers:
  • Authorization: Bearer bdb_live_YOUR_KEY
  • Content-Type: application/json
• Body type: Raw → JSON
• Body:

  {
    "query": "dentists",
    "country": "US",
    "city": "New York",
    "target_leads": 100
  }

• Parse response: Yes (so downstream modules can address fields by path).

The API returns one of two shapes:

• 200 with status: "done" and results: [...] inline (cache hit — common for popular queries).
• 202 with status: "submitted" and an id you have to poll.

For a weekly cron, the simplest pattern is: scope target_leads to a value you know is cacheable (≤ a few hundred), and route on status. If you need fresh scrapes for niche queries, add a follow-up "polling" module — Make has a built-in Sleep + Repeater combo for this. The pattern:

[Repeater 1..30]
   ├─ Sleep 10s
   ├─ HTTP GET /scrapes/{{id}}
   └─ Break if status == done

I keep a separate scenario for the polling case so the main one stays linear.

Step 2 — Iterator

The basedonb response has a results array. Drop a Make Iterator pointed at 1.results so each subsequent module runs once per lead.

Step 3 — HubSpot search (dedupe)

Most "leads pipelines" pollute the CRM because they re-add the same business every run. The cheapest dedupe is on phone number — basedonb returns E.164-ish strings (+12125550101) which HubSpot accepts as-is.

HubSpot module → "Search Objects":

• Object type: Contacts
• Filter: phone equals {{phone}}
• Limit: 1

Important: don't dedupe on website alone. Two businesses can share a website (chains). Phone is the cleanest unique key for SMB Google Maps data.

Step 4 — Router

Two routes off the search:

• Bundle exists → connect nothing (skip). Add a Set Variable skipped += 1 so the summary can mention it.
• Bundle missing → "Create Contact":
  • firstname: split {{title}} on space, take [0] (good enough for SMBs that aren't person-named — adjust if you're targeting solo practitioners)
  • phone: {{phone}}
  • website: {{website}}
  • company: {{title}}
  • address: {{address}}
  • hs_lead_status: NEW
  • Custom property lead_source: basedonb-google-maps
  • Custom property lead_rating: {{rating}}
  • Custom property lead_reviews: {{reviews_count}}

The rating and reviews_count fields are gold for prioritization — sort your sales queue by reviews_count DESC and you're calling real businesses, not zombie listings.

Step 5 — Aggregator + Slack

After the Router, drop a "Numeric Aggregator" with source = the create-contact module, function = count. The output is new_count.

Slack "Create a Message":

:dart: *{{new_count}}* new dentists in New York added to HubSpot.
{{skipped}} already existed (deduped on phone).
Top by reviews: {{top.title}} — {{top.reviews_count}} reviews, {{top.rating}}★

For the "top by reviews" bit, add a Sort + Get First between the iterator and aggregator on reviews_count desc.

Step 6 — schedule

Scenario settings → "Scheduling" → "Every week, Monday, 09:00".

Done. The full scenario is six core modules (HTTP, Iterator, HubSpot Search, Router, HubSpot Create, Aggregator + Slack).

Cost model

For 100 leads/week into HubSpot, deduped:

At 1k leads/week the basedonb cost drops to $0.009/lead (Growth tier — top up $40+) and you'll bump into Make's ops limit, so go to the $9/mo Core plan or self-host n8n. n8n doesn't have an official basedonb node yet, but the same HTTP Request node works against the same REST API — drop the JSON body in and the rest of the workflow ports 1:1.

Failure modes I hit (and how to fix them)

• Phantom dedupe misses. HubSpot phone search is exact-match. If basedonb returns +1 212-555-0101 and your old record has (212) 555-0101, they don't match. Fix: in the Router's "exists" branch, also search by website if phone normalization is messy. Or normalize both sides with a Make Text → Replace before search.
• Cache-hit confusion. First time you run a query you'll get a 202 and the rest of the scenario silently fails because 1.results is empty. Add an Error Handler on the HTTP module that routes 202 to the polling scenario instead.
• Rate limit / 503. basedonb returns 503 scraper_unavailable when its backend is briefly offline. Set the HTTP module's "Number of retries" to 3, "Initial interval" to 30s, exponential.
• Slack message length. If you list every new lead, you'll exceed Slack's 4k char limit. Cap at 5 examples and link to a HubSpot list view.

What I'd build next

If I were doing this seriously I'd:

1. Replace the cron with a dynamic territory queue — Airtable table of (query, city, last_run) and the scenario rotates through.
2. Add a website-alive check between dedupe and create — a 200 from HEAD {{website}} weeds out dead businesses faster than reviews count alone.
3. Add an enrichment pass — basedonb gives you the website, and a separate Hunter.io / Clearbit module turns that into emails. The CRM record is much more useful with both phone and email.

Final notes

The leverage here isn't that any one of these tools is special — it's that the connection is glue you don't have to maintain. I haven't touched this scenario in 4 months and it's still depositing 80–120 contacts/week into HubSpot.

If you build a variant — say, basedonb → Pipedrive, or basedonb → Airtable → Lemlist — drop a screenshot in the comments. I'm collecting these into a public scenario library.

— basedonb · open to feedback.