DEV Community: Techforce Global

Build a LinkedIn Candidate Shortlist in Python Without a LinkedIn Cookie

Techforce Global — Thu, 24 Sep 2026 12:05:59 +0000

If you've ever been asked to "just pull a list of senior Java devs in Pune" for the hiring team, this post is for you. We'll build a candidate shortlist from public LinkedIn profiles in about 15 lines of Python, with no LinkedIn account, no cookie and no li_at token.

We'll use LinkedIn Candidate Search (No Cookies), an Apify Actor we built at Techforce Global. It composes the X-ray search query for you, runs it through Brave Search and returns structured results.

1. Install the client

pip install apify-client
export APIFY_TOKEN=your_token_here

2. Describe the role and run it

import os
from apify_client import ApifyClient

client = ApifyClient(os.getenv("APIFY_TOKEN"))

run = client.actor("techforce.global/linkedin-candidate-search").call(run_input={
    "job_role": "Java Developer",
    "seniority": "Senior",
    "technologies": ["Spring Boot", "Kafka"],
    "exclude_keywords": ["recruiter", "intern"],
    "location": ["Pune", "Mumbai"],
    "max_profiles": 20,
    "deliveryMode": "none",
})

items = client.dataset(run["defaultDatasetId"]).list_items().items
print(f"{len(items)} candidates")

3. Read the results

Each item has four fields:

{
  "name": "Aditi Ranganathan",
  "title": "Senior Java Developer at FinServe Systems",
  "profile_url": "https://in.linkedin.com/in/aditi-ranganathan-1a2b3c",
  "snippet": "Senior Java Developer with 8 years building Spring Boot microservices..."
}

The snippet is your best relevance signal, so filter on it:

strong = [c for c in items if "kafka" in (c["snippet"] or "").lower()]
for c in strong:
    print(c["name"], "|", c["title"], "|", c["profile_url"])

Gotchas worth knowing

Always set a search signal. Set at least one of job_role, technologies or keywords. With none, the Actor falls back to a default query and you get unrelated results.
Max 50 per run (5 on free plans). For more, loop by city or seniority.
The query is capped at 450 characters. Very long tech lists get cut. Keep briefs tight.
Dedupe on profile_url across runs.
No emails or phone numbers. It's search-result depth by design.

Bonus: call it from an AI agent

It's a native MCP tool, so you can add it to Claude Code:

claude mcp add --transport http apify "https://mcp.apify.com?tools=techforce.global/linkedin-candidate-search"

Then just ask: "Find 20 senior React developers in Bangalore, no recruiters."

Full input reference, JavaScript and cURL examples: LinkedIn Candidate Search (No Cookies) - Talent Sourcing API

Building a Finance Lead Pipeline with the Google Maps Lead Scraper API

Techforce Global — Wed, 09 Sep 2026 13:00:00 +0000

This actor covers 28 finance business types, five optional intelligence blocks, and MCP delivery into six different destination apps enough surface area that a proper API walkthrough is worth more than the standard input/output table. This post covers a real Python integration, the MCP connector delivery modes, and the specific execution rules worth knowing before you build a production pipeline on top of it.

The gap between reading the README and building a working pipeline usually comes down to a handful of quiet behaviours that don't show up until a run returns something unexpected a silent fallback here, an omitted field there. This post front-loads those specifically, since they're the difference between a pipeline that works the first time and one that needs a debugging session to figure out why results look wrong.

Authentication

Standard Apify bearer token auth applies for direct API calls available from Settings → Integrations in your Apify account. No target-site credentials are needed at all; the actor reads only public Google Maps listings and public website content, so there's no separate authentication layer for the data source itself, unlike the official Google Places API, which requires a GCP project and a billing-enabled key.

Input configuration the essentials

Error handling the codes worth checking for explicitly

This actor documents its own error/condition matrix in unusual detail, which is worth taking advantage of directly in your integration code rather than treating every non-success as a generic failure.

SILENT_DEFAULT - results are CA Firms in London you never asked for, because no field is required and both defaulted. Always pass subcategories and location explicitly to avoid this entirely.
CAP_REACHED - itemCount equals maxResults equals 100, meaning the per-run ceiling truncated results. Partition larger jobs across sequential runs.
FREE_PLAN_CAP - itemCount caps at 10 with an upgrade banner in the log. This is a successful run, not a failure worth distinguishing in your monitoring so it doesn't trigger a false alert.
EMPTY_RESULTS - status SUCCEEDED with itemCount 0. Also not a failure it means the business type and location combination genuinely had no Google Maps matches.
DELIVERY_SKIPPED an MCP connector was set but mcpTool was left empty, so the delivery step is skipped with a warning while the dataset is still written in full.

Running it Python

import os
from apify_client import ApifyClient

client = ApifyClient(os.getenv('APIFY_TOKEN'))

run = client.actor('techforce.global/finance-google-maps-lead-scraper').call(run_input={
    'subcategories': ['CA Firm', 'Accounting Firm', 'Tax Consultant'],
    'location': 'London',
    'maxResults': 90,
    'includeLeadOverview': True,
    'includeWebsiteHealthScorecard': True,
    'includeServiceRecommendations': True,
    'includeTechnicalIntel': False,
    'deliveryMode': 'none',
})

items = client.dataset(run['defaultDatasetId']).list_items().items
firms = [i for i in items if i.get('businessName')]

weak_sites = [
    i for i in firms
    if i.get('WEBSITE_HEALTH_SCORECARD', {}).get('finalGrade') in {'C', 'D', 'F'}
]
print(f'{len(weak_sites)} firms with a weak website — best prospects')

Execution rules that will bite you if skipped

Nothing is required. An empty input {} silently scrapes 'CA Firm in London' rather than raising an error — always pass subcategories, location, and maxResults explicitly from API or MCP calls
subcategories values must match the 28-item enum exactly — 'ca firm' (lowercase) or an unlisted type like 'Hedge Fund' gets logged as a warning and skipped; if every value is invalid, the actor silently falls back to 'CA Firm'
Empty fields are omitted from each item, not set to null — always check key presence ("website" in item), never compare to None
A missing email is the literal string "NA", not an empty value — check emailStatus first (ok / no_email_found / failed / no_website)
maxResults is split evenly across every selected business type — 10 types with maxResults: 100 gives roughly 10 practices each, not 100 each

MCP connector delivery pushing straight to Slack

This actor supports four delivery modes: summary (one digest call), chunked (split across calls for long lists), perLead (one call per practice), or none. Setting up a Slack digest for every run looks like this:

{
  "subcategories": ["Insurance Broker", "Life Insurance Agency"],
  "location": "Manchester",
  "maxResults": 60,
  "mcpConnector": "<your-authorized-slack-connector>",
  "deliveryMode": "summary",
  "mcpTool": "send_message",
  "mcpArguments": { "channel": "#finance-leads", "text": "{message}" },
  "mcpMessageTemplate": "{leadCount} {subcategories} leads in {location}:\n\n{leads}"
}

For a long lead list going into Notion specifically, chunked mode groups lead lines into parts under roughly 72,000 characters each, so services with per-request size limits Notion in particular never reject the call.

Choosing a delivery mode for the right use case

Summary mode makes sense for a scheduled digest one message per run, listing every lead found. Chunked mode exists specifically for services with strict per-request size limits, splitting a long lead list into numbered parts. PerLead mode fires one connector call per individual practice, which is the right choice for pushing directly into CRM records but risks connector rate limits on a large batch a 100-practice run in perLead mode against a rate-limited service is a common source of dropped calls, worth testing on a small batch before scaling up.

Frequently asked

What's the fastest way to get a contacts-only run?
Set all five include* toggles to false this skips the website crawl and audit entirely and returns just the base practice profile.

How do I avoid overspending on a large automated run?
Pass maxTotalChargeUsd as a query parameter on the run endpoint for a hard per-execution spend ceiling important for any pipeline running unattended.

Why did my run return fewer items than maxResults?
This is expected the budget splits across business types, duplicate listings are removed, and Google may simply have fewer matches for that type/location combination than requested.

Can I search more than 100 practices in one call?
No 100 is a hard per-run ceiling. Partition by city or business-type group across sequential runs and merge on googleMapsUrl

Getting started

Full documentation and the interactive input schema:
Finance Google Maps Lead Intelligence Scraper

The Engineering Case for AI in Europe's Trucking Industry

Techforce Global — Wed, 09 Sep 2026 09:32:53 +0000

The conversation around Europe's truck driver shortage often focuses on recruitment. That makes sense, but it leaves out an important part of the problem: the amount of operational work surrounding every driver.

Dispatchers answer calls. Drivers provide status updates. Customers request delivery information. Recruiters process applications. Operations teams coordinate schedules and handle exceptions.

Much of this work is repetitive and predictable.

That makes logistics an interesting environment for applied AI.

Think in Workflows, Not Chatbots

A useful AI system for a transport company should not exist simply to answer questions.

It should be connected to a workflow.

Consider a driver calling to report a delayed loading appointment. A basic chatbot might provide a generic response. A properly integrated AI voice agent could identify the driver, understand the shipment context, capture the delay, update the appropriate system through an API, and escalate the issue when a human decision is required.

The difference is significant.

The first system produces conversation. The second completes work.

This distinction should guide how logistics companies evaluate AI projects.

For a broader look at how AI can address operational pressures associated with Europe's driver shortage, see AI and Europe's truck driver shortage.

Why Voice Interfaces Make Sense

A traditional software interface assumes that the user can stop what they are doing and interact with a screen.

A driver often cannot.

That makes voice a compelling interface for specific logistics tasks.

Drivers can provide updates verbally while keeping their attention on the job. AI can convert the conversation into structured information and pass it into the relevant workflow.

Potential use cases include:

Delivery status updates
Appointment changes
Basic dispatch enquiries
Driver check-ins
Customer delivery notifications
Recruitment screening and scheduling

Not every task is appropriate for voice automation. The key is choosing interactions where conversation is already the natural method of communication.

Data Collection Is Another Opportunity

AI automation becomes more effective when businesses have clean, structured information.

Recruitment provides a simple example. Transport companies need information such as driving experience, licence details, availability, location, and contact information. Collecting that information consistently can reduce unnecessary back-and-forth.

AI can then operate around that structured information rather than trying to interpret scattered emails and documents.

Integration Is the Hard Part

The most impressive AI demo can still fail when it reaches production.

A logistics AI system may need to communicate with transportation management systems, CRM platforms, scheduling tools, telephony providers, databases, and internal applications.

That introduces familiar engineering concerns: authentication, API reliability, permissions, monitoring, error handling, logging, and data security.

It also creates an important architectural principle: an AI agent should have only the access it needs to perform its assigned task.

For example, an agent responsible for appointment scheduling does not necessarily need unrestricted access to fleet or financial systems.

Human Escalation Should Be Designed In

Automation works best when its boundaries are explicit.

If an AI agent encounters an unusual delivery issue, a safety concern, a dispute, or a request outside its permissions, it should know when to stop and involve a person.

Good escalation design is not a weakness. It is part of production-grade automation.

The objective is to remove repetitive work while preserving human control over decisions that require judgment.

A Practical Starting Point

Companies considering AI should resist the temptation to launch a huge transformation program immediately.

Choose one workflow with high transaction volume and measurable friction.

Automate it. Integrate it with the existing systems. Monitor the results. Then improve the workflow based on real usage.

For Europe's logistics sector, AI will not solve the driver shortage by itself. But it can reduce the administrative burden surrounding drivers, help operations teams work more efficiently, and make limited human capacity go further.

That is a much more practical, and ultimately more valuable definition of AI adoption.

Building AI Voice Agents for European Businesses: What Actually Matters

Techforce Global — Wed, 26 Aug 2026 19:12:46 +0000

AI voice technology has moved beyond simple IVR replacement.

Today's voice agents can understand natural language, maintain conversational context, connect with APIs, and trigger business workflows. That creates interesting possibilities for European companies but building a useful voice agent requires considerably more than connecting a speech model to a phone number.

The engineering decisions behind the system often determine whether the result becomes a reliable business tool or an impressive demo that fails in production.

Start With the Workflow, Not the Model

A common mistake is choosing an AI model first and then searching for a problem it can solve.

A better approach is to map the workflow.

Consider appointment scheduling. The system needs to understand what the caller wants, collect the required information, check availability, book the appointment, confirm the details, and handle exceptions.

The language model is only one component.

A production architecture may also require speech-to-text, text-to-speech, authentication, business APIs, databases, observability, access controls, and escalation logic.

The business workflow should therefore define the architecture not the other way around.

Integrations Are Where Voice AI Becomes Useful

A voice agent that can only answer general questions has limited operational value.

The real advantage appears when it can interact with existing systems.

For example, a customer might call a logistics company to ask about a delivery. The agent could authenticate the customer, retrieve shipment information through an API, explain the current status, and create a support ticket if something has gone wrong.

That requires reliable integration between the conversational layer and backend systems.

For teams evaluating the broader use cases, this overview of AI voice agents for European businesses offers useful context around where conversational automation can fit into business operations.

Europe Adds Another Engineering Layer

European deployments introduce additional considerations around privacy, security, language support, and regulatory requirements.

A voice system may need to support several languages and regional accents while maintaining consistent intent detection. At the same time, organizations need to understand where conversation data is processed, how long it is retained, and which systems the agent can access.

This makes data architecture especially important.

Sensitive information should not simply flow through every component of the application. Permissions should be scoped to specific tasks, and important actions should be logged for auditing and troubleshooting.

Design for Failure From Day One

Voice conversations are unpredictable.

Customers interrupt. They change their minds. Background noise affects transcription. APIs fail. A caller may provide incomplete information or ask something outside the system's defined capabilities.

Production voice agents therefore need graceful failure paths.

Instead of guessing, the agent should be able to clarify the request, retry an operation, or transfer the conversation to a human.

Human escalation is particularly important for complex or sensitive interactions. The handoff should also preserve relevant conversation context so the customer does not have to explain everything again.

Measure Business Outcomes, Not Just Conversation Quality

A voice agent can achieve impressive language-model evaluation scores and still provide little business value.

Engineering teams should track operational metrics such as task completion rate, successful transfers, average handling time, escalation frequency, booking accuracy, API failure rates, and customer drop-off.

These measurements reveal whether the system is actually improving the process.

For example, reducing average call duration is not necessarily positive if more customers require repeat calls. Likewise, increasing automation rates may be counterproductive if customers cannot reach a human when they need one.

The right metrics depend on the workflow.

Build Narrow, Then Expand

The strongest approach is usually to start with one clearly defined use case.

Appointment scheduling, order-status enquiries, candidate screening, reservation management, or basic customer support can provide controlled environments for testing.

Once the system performs reliably, additional workflows can be introduced.

This incremental approach makes it easier to evaluate accuracy, security, integration reliability, and user experience without turning the first deployment into an unnecessarily complex platform.

AI voice agents are ultimately less about making phone conversations sound intelligent and more about connecting natural language with dependable software systems.

For European businesses, that means combining conversational AI with thoughtful architecture, secure integrations, clear operational boundaries, and human oversight. When those pieces work together, voice automation becomes more than a chatbot on a phone it becomes another interface to the business itself.

From Google Maps to a Sales Pipeline: How I Realized Scraping Was the Easy Part

Techforce Global — Wed, 26 Aug 2026 13:54:29 +0000

A build story for the Google Maps Business Leads Scraper & Sales Intelligence Actor

When I first started working on this Actor, the idea was actually pretty simple.

I wanted to build a Google Maps scraper that could help us find businesses and collect their basic information: business name, address, phone number, website, Google rating, reviews.

Nothing too complicated. And it worked.

But after looking at the output, I had the same thought I've had with a lot of scraping projects: okay, I have the data, now what?

A salesperson doesn't need another CSV with 500 business names. They need to know which businesses are worth contacting, why they should contact them, and ideally, they shouldn't have to spend three hours opening websites one by one to figure that out.

That was the point where this stopped being a Google Maps scraper for me. I wanted to turn it into a lead intelligence tool.

The problem: manual research is where the time disappears

The original problem was manual effort. A salesperson might start with something as simple as "search for resorts in Los Angeles." Then comes the actual work open Google Maps, check the business, open the website, find an email, check whether the website is actually good, look for SEO problems, look for technical problems, try to understand what service could be sold to that business, then decide whether the lead is worth contacting. Repeat for dozens or hundreds of businesses.

Scraping is the easy part. The manual research after scraping is where the time disappears. So I started asking whether the Actor could do more of that work automatically.

The first version was just a Google Maps scraper

I started with the basic version: search Google Maps → collect businesses → return structured data. That proved the idea worked, but there was nothing special about it. There are already loads of Google Maps scrapers on Apify I didn't want to build another one just because I could.

So instead of asking "how can I scrape more businesses," I asked: what information would actually help a salesperson make a decision? That changed the direction of the project.

From scraping to sales intelligence a real run, with real numbers

The Actor now starts with Google Maps, but it doesn't stop there. In one of my tests I searched "Resorts", location “Los Angeles”, capped at 10 businesses, with all four intelligence modules enabled: Sales & Growth Strategy, Website Performance Report, Suggested Business Improvements, and Website Technology Details

The Actor visits the Google Maps results, collects the business information, then visits the business website and starts analyzing it this is where Playwright matters, since the Actor needs to work with real rendered websites, not static HTML responses.

Here's a, run, with actual Console evidence rather than just a description:

Run: "Resorts" in "Los Angeles" - 10 results, 2m 28s, succeeded 2026-08-26

The actual configuration for this run:

run_input = {
    "searchQuery": "Resorts",
    "location": "Los Angeles",
    "subcategory": "",
    "maxResults": 10,
    "includeSalesStrategy": True,
    "includeServiceRecommendations": True,
    "includeTechnicalIntel": True,
    "includeWebsiteHealthScorecard": True,
    "deliveryMode": "summary",
    "mcpConnector": "<your Notion connector ID>",
    "mcpTool": "notion-create-pages",
    "mcpArguments": {
        "parent": {"page_id": "<your Notion page ID>"},
        "pages": [
            {
                "properties": {
                    "title": "Leads: {searchQuery} in {location} ({leadCount})"
                },
                "content": "{leads}"
            }
        ]
    },
    "proxyConfiguration": {"useApifyProxy": False}
}

Run it with the Apify client:

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")
run = client.actor("techforce.global/google-maps-leads-sales-intelligence-tool").call(run_input=run_input)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["businessName"], item["googleRating"], item["totalReviews"])

The output columns from that run: business name, company email, phone, address, Google rating, total reviews, category, website, social media, Google Maps URL, search query, and a Business Growth Opportunity block generated per lead.

The final result isn't just a business record. It's a combination of business data, website intelligence, and sales intelligence and that combination is the part I actually cared about.

What does the output look like?

Here's an actual result from the Four Seasons test run.

Business name: Four Seasons Hotel Los Angeles At Beverly Hills
Address: 300 S Doheny Dr, Los Angeles, CA 90048
Phone: (310) 273-2222
Google rating: 4.6
Total reviews: 2,411
Website: Available
Company email: No email found
That alone is useful. But the interesting part starts after that the Actor generated a lead overview:

Lead priority: Hot Lead
Revenue opportunity: High
Sales angle: Strong reputation but website trust and SEO polish gaps
Estimated monthly service potential: $300–$900
Estimated one-time project potential: $900–$2,400

Instead of saying "here's a hotel with a 4.6 rating," I can say: "this business already has strong social proof, but there are website trust, SEO, and conversion opportunities worth discussing." That's a much better starting point and it was probably the biggest shift in the whole project. I stopped thinking about the output as scraped data. I started thinking about it as a sales decision.

A note on differentiation: at the time of writing I don't yet have a saved example of a Low Priority lead to show side by side I've seen the Actor produce them, but I didn't keep one from an earlier run. What I can show instead is exactly how the tool tells the two apart, which is arguably more useful than one more example: see the scoring logic below.

How lead priority and recommendations actually get decided

I didn't want "Hot Lead" to be a field that just sounds confident without any reasoning behind it. Here's the actual shape of the logic, with exact thresholds abstracted since this is scoring logic I'd rather not hand verbatim to every other Google Maps scraper on the market:

recommendations: list[dict] = []
for field, service, required_work, expected_impact, why_this_matters, expected_after_update in service_rules:
    score = float(scores.get(field, 0) or 0)
    if score >= HIGH_QUALITY_THRESHOLD:
        continue  # already strong, no recommendation needed
    priority = "High" if score < LOW_QUALITY_THRESHOLD else "Medium"
    grade, classification = grade_from_score(score)
    recommendations.append({
        "service": service,
        "priority": priority,
        "currentGrade": grade,
        "professionalClassification": classification,
        "requiredWork": required_work,
        "expectedImpact": expected_impact,
        "whyThisChangeMatters": why_this_matters,
        "whatWillBeAchievedAfterUpdate": expected_after_update,
    })

if not recommendations:
    # Every scored category came back strong — recommend monitoring, not a rebuild
    recommendations.append({
        "service": "Website Monitoring and Continuous Optimization",
        "priority": "Low",
        "currentGrade": "A",
        "professionalClassification": "Growth-ready: maintain current quality through regular checks",
        "requiredWork": "Monitor speed, SEO, security headers, structured data, and conversion paths after every website update.",
        "expectedImpact": "Keeps the website stable, competitive, and ready for future growth.",
        "whyThisChangeMatters": "A strong website can still lose performance over time as plugins, content, tracking scripts, and search requirements change.",
        "whatWillBeAchievedAfterUpdate": "Regular monitoring should preserve website quality, keep growth campaigns stable, and help catch issues before they affect leads or revenue.",
    })

recommendations.sort(key=lambda item: {"High": 0, "Medium": 1, "Low": 2}.get(item["priority"], 3))

In plain language: each website gets scored across several categories (SEO, security, performance, and a few others). Anything scoring above the high-quality threshold gets skipped no point recommending work on something that's already solid. Anything below the lower threshold becomes a High priority recommendation; the middle band becomes Medium. If a business scores well across the board, instead of returning nothing, the Actor recommends ongoing monitoring rather than forcing a fake "issue" just to have something to say. Recommendations are then sorted so the highest-priority, highest-impact items surface first.

That's also why a Hot Lead and a genuinely well-optimized business get treated differently under the hood, even if both show up with good Google ratings — the lead score and the website-quality score are measuring different things.

The website analysis: every site is different

Once the Actor had the business information, the next challenge was pulling something useful from the website itself and this wasn't as straightforward as I expected. Some sites load fast, some don't. Some have clean HTML, some rely heavily on JavaScript. Some expose an email, some don't. Some have good SEO, some look untouched since 2014 and some manage to have both problems and a great Google rating.

The Actor checks multiple parameters before generating its technical and sales analysis. For the Four Seasons test, the generated analysis flagged issues around on-page SEO, SSL/security, and technical SEO which gives a salesperson something concrete to open a conversation with:

Not: "Hi, we provide digital marketing services."

But something closer to: "We noticed that your business already has strong reviews and a good online foundation, but there are a few trust, SEO, and conversion improvements that could help improve enquiry confidence and organic visibility."

The first message sounds like an advertisement. The second one sounds like someone actually looked at the business. That difference was the entire goal.

The hardest problem wasn't scraping Google Maps

Ironically, the hardest part of this project wasn't Google Maps, and it wasn't even getting the website data. It was accuracy. If I'm going to give a salesperson a field called "Hot Lead," I need to be careful about what that actually means. If I say a business has a high revenue opportunity, there should be reasoning behind it, not a generic template with the business name inserted.

The way I actually tested this: run it, look at the result, find something that doesn't make sense, change the implementation, run it again, check the output again, repeat. One concrete example early on, businesses with genuinely excellent websites were still occasionally getting flagged with generic "improve your website" recommendations, because the scoring only looked at surface-level signals like page load time. Adding the category-by-category threshold logic above (rather than one blended score) is what fixed that a business can now score well on security but poorly on SEO, and get a recommendation that reflects the actual gap instead of an average that hides it.

There wasn't a magic switch that made results suddenly perfect. It was a lot of small improvements, and it's the least glamorous part of building a tool like this you don't see it on the Actor page, but it's where most of the work happens

The timeout problem

The basic Google Maps scraping was relatively fast. Once I added website analysis, technical analysis, and sales intelligence, every business became more expensive in execution time the Actor wasn't doing one operation anymore, it was doing several per business. If I scrape 100 businesses, I don't just have 100 Google Maps pages, I potentially have 100 websites that also need visiting and analyzing.

That's a genuinely different performance problem, and it meant keeping a close eye on execution time to keep the whole thing practical to run on the Apify platform which is also one of the reasons I like building on Apify: I don't have to build and manage the infrastructure around the crawler myself. I can focus on the Actor's actual logic.

What I actually used from Apify

Actor : the core execution unit
Playwright : handles browser-based website interaction, since static HTML fetching isn't enough for modern sites
Dataset : where structured lead results go
Key-value store : useful for data that doesn't fit a table-like dataset
Integrations : what turns the output into part of another workflow, not a dead end

Each run gets its own dataset and key-value store, which is convenient for development and testing I don't have to build a storage layer around every scraping project. I build the Actor, run it, and inspect results from the Console or the API.

The development cycle was short testing it properly wasn't

The first usable version took two to three days, but that doesn't mean two days of coding and done. I tested the Actor against hundreds of businesses during that process. The goal wasn't just making the Actor run successfully a run finishing with status "SUCCEEDED" is not the same thing as a run producing something anyone wants to use. That distinction mattered more than I expected going in.

The Apify Console made this testing loop much easier, since I could see input, logs, output, and storage for each run without building separate tooling. The runs used Apify SDK 3.4.1, Apify Client 2.5.1, and Crawlee 1.9.1.

From dataset to actual sales workflow

I didn't want the output to live forever inside an Apify dataset a sales team isn't going to open Apify every morning to check a dataset. They already have tools they use. For this workflow, results get pushed directly into Notion via Apify's MCP connector, using the notion-create-pages tool each run creates a page under a parent Notion page, titled with the search query, location, and lead count, with the leads themselves as page content.

So the pipeline is: Google Maps → the Lead Intelligence Actor → Apify Dataset → Notion → the sales workflow. The Actor isn't sitting at the end of the pipeline as a scraper it's one component in the middle of it. The same output could just as easily be pushed into a CRM, sent through an n8n workflow, or used to trigger another Actor entirely, since Apify supports Actor-to-Actor workflows where one Actor's output becomes the next step's input or trigger.

Why Apify?

I could have built the infrastructure myself managed browser instances, managed proxies, built storage, handled scaling and deployment and monitoring and eventually gotten back to the actual problem I wanted to solve. I didn't want to do that. Apify gives me a developer-friendly platform where I can focus on building the Actor instead of the infrastructure around it, and proxy support mattered too infrastructure problems can quickly become the project if you're not careful, and I wanted the project to stay the Actor.

What I would do differently next time

If I were starting this again, I'd talk to more salespeople before writing the first line of code not developers, not scraping experts, actual salespeople and agencies. What do you actually look at before contacting a lead? What makes you reject one? Which website problems are actually worth knowing? What makes a lead "hot" for you? What information helps you personalize a first message, and what's completely useless?

I built a lot of the intelligence based on what I thought would be useful. That works to a point, but there's a difference between "this is interesting information" and "this information actually changes whether I contact this lead." The second one is what I'd optimize for if I rebuilt this today I'd rather have ten highly useful fields than fifty nobody looks at.

Where I want to take this next

The current version can discover businesses, collect their information, visit their websites, analyze technical aspects, generate website health information, identify improvements, and generate sales-oriented intelligence. But I don't think the interesting part ends there.

Instead of just saying "Hot Lead," I want to surface why. Instead of just giving a sales angle, I want the salesperson to understand why that angle was selected. Instead of just generating a recommended pitch, I want the recommendation traceable back to actual signals from the business and its website not a black box.

The original idea was a Google Maps scraper. That version worked, but it wasn't enough. The interesting part started when I stopped asking "how many businesses can I scrape" and started asking "what can I tell a salesperson that will actually save them time." That question changed the entire project, and it's probably the biggest thing I learned building it.

Scraping the data is only half the job. Making the data useful is the real work. And sometimes the best scraper isn't the one that gives you the most data it's the one that makes you open the next lead and think: okay, this one is actually worth calling.

FAQ

Does this work for any business category, or just hotels and dental practices?
The Actor works with any Google Maps search query and location — the examples in this article (resorts, dentists) are just what I happened to test with. The intelligence modules apply the same scoring logic regardless of category

How is "Lead Priority" actually calculated?
Each business's website is scored across several categories (SEO, security, performance, and others). Scores below a threshold generate prioritized recommendations; scores above it don't. See the scoring logic section above for the actual (lightly abstracted) code.

What happens if a business has no email or no website at all?
The Actor still returns the Google Maps data (name, address, phone, rating, reviews) website-dependent fields like technical intel and website health scoring are simply left empty rather than guessed at.

Can I deliver results somewhere other than Notion?
Yes, Apify's MCP connector supports multiple delivery targets (Slack, Airtable, Google Sheets, and others depending on what's configured on your account). The dataset is always written in full regardless of delivery settings.

Try it yourself: Google Maps Business Leads Scraper & Sales Intelligence on Apify start with a small maxResults value (5–10) to see the output shape before scaling up a run.

Building an AI Agent Workflow with a LinkedIn MCP Connector

Techforce Global — Wed, 26 Aug 2026 08:00:00 +0000

Most tutorials on MCP cover the protocol in the abstract the spec, the message format, a toy example. This post is the opposite: a working walkthrough of wiring a real MCP connector (this actor, which finds LinkedIn decision makers) into an agent, plus the API-level details for anyone who wants to call it directly instead of through an MCP client.

If you've read the protocol docs and still aren't quite sure what an actual integration looks like end to end, this should close that gap three concrete paths (MCP client, direct API, real-time endpoint), each with working code, so you can pick whichever fits your existing stack rather than starting from the spec every time.

The two directions of MCP on Apify, and which one this uses

Apify's own MCP server exposes actors as tools TO outside AI clients Claude, Cursor, and others discover and call Apify actors as part of their toolset. MCP connectors work in the opposite direction: an actor calls OUT to a third-party service (Notion, Slack, Jira) on the user's behalf. This actor supports both it can be called as a tool by an agent, and it can push its own results out via a connector. Understanding which direction you're working with matters, since the setup differs, and mixing them up is the most common early confusion when first working with MCP-enabled actors.

Connecting via MCP client config

If you're using Claude Desktop, Cursor, or another MCP-compatible client, connecting to Apify's hosted MCP server looks like this:

{ "mcpServers": { "apify": { "url": "https://mcp.apify.com", "headers": { "Authorization": "Bearer YOUR_APIFY_API_TOKEN" } } } }

Once connected, the agent can discover and call this actor (and any other Apify actor) as a tool, passing companyName as an argument the same way it would call any other function.

Calling it directly via API Python

import requests

api_token = 'YOUR_APIFY_API_TOKEN'
actor_id = 'techforce.global~linkedin-company-decision-makers'

response = requests.post(
    f'https://api.apify.com/v2/acts/{actor_id}/runs',
    headers={'Authorization': f'Bearer {api_token}'},
    json={'companyName': 'Acme Corp', 'exactMatch': True}
)
dataset_id = response.json()['data']['defaultDatasetId']`

## Using the real-time Standby endpoint Node.js
For agent workflows that need an instant answer rather than waiting on an async run, the Standby mode exposes a live HTTP endpoint:

`const response = await fetch(
  'https://techforce-global--linkedin-company-decision-makers.apify.actor/lookup',
  {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer YOUR_APIFY_TOKEN',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ companyName: 'Acme Corp' })
  }
);
const decisionMakers = await response.json();
console.log(decisionMakers[0]);
// { name, linkedin_url, title, location, headline }

The Standby endpoint is capped at a small number of free profiles for testing, with a higher limit on paid plans worth checking current limits before building a high-volume real-time integration around it.

Setting up an MCP connector to push results to Notion

Go to Apify Account Settings → API & Integrations → MCP connectors
Authorise a new connector, selecting Notion Apify provides automatic OAuth setup for Notion, so this is a one-click authorisation, not a manual API key exchange
When configuring a run of this actor, select the authorised Notion connector from the picker the actor will push results into the connected Notion database automatically on completion

Output schema reference

Authentication and credential handling

For the MCP client and direct API paths, your Apify API token authenticates the request standard bearer token auth, available from Settings → Integrations in your Apify account. For the connector path specifically, your Notion/Slack/Jira credentials never pass through this actor's code at all Apify's platform holds the authorised connection and injects it server-side at runtime, which is worth knowing if credential handling is something your security team asks about before approving an integration.

Error handling

As with any scraping-based actor, individual lookups can return no results a company with no meaningful LinkedIn presence, or a name specific enough that exact matching finds nothing. Check for an empty result set explicitly in your integration code rather than assuming every lookup returns at least one decision maker.

For the async batch path specifically, poll the run status endpoint until it reports SUCCEEDED before fetching the dataset treating FAILED or ABORTED runs as an explicit case in your code avoids a pipeline silently proceeding with empty or partial data.

Common integration patterns

Agent-triggered lookup : an agent calls this as an MCP tool mid-conversation, using the Standby endpoint for a fast response
Scheduled enrichment : a batch run against a fixed list of target companies, on a weekly or monthly schedule, pushing results to Notion via connector
Event-triggered : a new row in a CRM or spreadsheet triggers a real-time lookup via a webhook-driven automation (n8n, Make, or a custom function)

The scheduled-enrichment pattern is worth a closer look for teams managing an ongoing pipeline rather than a one-time list. Wiring this actor into a weekly n8n or Make workflow trigger, run, fetch results, push to Notion via the connector turns decision-maker research from something someone remembers to do manually into something that simply happens, with the team only reviewing the output rather than generating it.

Frequently asked

Do I need to use the MCP connector, or can I just get a normal dataset?
Both are supported connector output is optional, not required. Skip it entirely and use the standard Apify dataset if you don't need direct third-party delivery.

Can I chain this with other Apify actors in one agent workflow?
Yes, since Apify's MCP server exposes all actors as tools, an agent can call this actor and any other actor (like a contact-enrichment tool) in the same session, chaining outputs together.

What's the rate limit on the Standby endpoint?
This depends on your Apify plan tier check current limits in your account before building a high-frequency real-time integration.

Can I test the connector setup without a real Notion/Slack workspace?
Not directly for the connector delivery itself, since it requires an authorised real connection but you can fully test the actor's data output via the standard dataset API first, then add the connector once you're confident in the data, decoupling the two concerns during development.

Getting started

Full documentation and the interactive input schema:
LinkedIn Decision Makers MCP Connector for Notion & Slack

Building an Agency Sourcing Pipeline with the TopDevelopers.co API

Techforce Global — Wed, 12 Aug 2026 09:47:15 +0000

If you're building an internal tool for vendor sourcing, CRM enrichment, or partnership discovery, pulling agency data from TopDevelopers.co programmatically beats manual research the same way any API beats manual browsing but the interesting part isn't the extraction, it's what you do with the enrichment layer once you have it. This post covers the actor's input/output schema, two full working integration examples, and a few practical patterns for using this as part of a larger pipeline rather than a one-off pull.

Most agency-directory scrapers stop at raw listing data name, rating, maybe a website. What makes this API worth integrating rather than just running manually through the Apify Console is the enrichment layer: a real email pulled from the agency's own site rather than a directory contact form, and an insights object that turns unstructured review text into something you can actually filter and sort on programmatically.

Authentication

Like any Apify actor, this runs through the standard Apify REST API. You'll need an API token from your Apify account under Settings → Integrations, passed either as a Bearer header or a query parameter depending on which endpoint you're calling.
Input schema

At least one of searchQuery, companyName, or selectedDomain must be set.
**Starting a run Python*

import requests

api_token = 'YOUR_APIFY_API_TOKEN'
actor_id = 'techforce.global~it-agency-lead-finder-enricher-topdevelopers-co'

response = requests.post(
    f'https://api.apify.com/v2/acts/{actor_id}/runs',
    headers={'Authorization': f'Bearer {api_token}'},
    json={
        'searchQuery': 'Flutter developers in UAE',
        'maxResults': 50,
        'maxReviewsPerCompany': 5
    }
)
dataset_id = response.json()['data']['defaultDatasetId']

Fetching and filtering results

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)

agencies = requests.get(
    f'https://api.apify.com/v2/datasets/{dataset_id}/items',
    params={'token': api_token}
).json()

top_agencies = [a for a in agencies if a.get('rating', 0) >= 4.5 and a.get('email') != 'NA']
print(len(top_agencies), 'qualified agencies with email')

Node.js pushing enriched profiles to a CRM

const { ApifyClient } = require('apify-client');
const client = new ApifyClient({ token: 'YOUR_APIFY_TOKEN' });

const run = await client.actor(
  'techforce.global/it-agency-lead-finder-enricher-topdevelopers-co'
).call({
  selectedDomain: 'Ecommerce Development',
  selectedCategory: 'platform:shopify',
  maxResults: 30
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
const withBudgetFit = items.filter(a =>
  a.insights?.common_project_budgets?.some(b => b.includes('$10,001'))
);

await fetch('https://your-crm.example.com/webhook/vendors', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(withBudgetFit)
});

Output schema full reference

Filtering on the insights object

The insights.common_project_budgets and insights.top_project_types fields are arrays of strings rather than structured ranges, since they're derived from natural-language review content. Matching on substring, as in the Node example above, is the practical approach checking whether a budget bracket string like "$10,001 - $50,000" appears in the array rather than trying to parse them into strict numeric ranges, which risks breaking if the underlying review phrasing varies.

This matters for anyone building automated scoring on top of the raw data: treat insights fields as signals to combine with your own weighting logic, not as a substitute for a full lead-score calculation. A practical middle ground is a simple point system award points for rating above a threshold, more points for a matching budget bracket, more again for a matching project type and sort by total rather than trying to build a single authoritative score into the pipeline itself.

Handling the two-tier pricing in code

Since basic (listing-only) and enriched (full profile) results are priced differently, a cost-conscious integration pattern is to run a broad basic search first to map out the category, then a second, narrower enriched run against just the shortlist that passed initial filtering — rather than enriching every result from the first pass. This mirrors the manual research pattern of browsing broadly first and only digging deep on serious candidates, just automated.

In practice this means two API calls chained together: the first with a higher maxResults and no need for maxReviewsPerCompany depth, the second with a much smaller maxResults (just the shortlist) but a higher maxReviewsPerCompany, since review depth matters more once you're down to serious candidates.

Common integration patterns

Manual pull a BD or procurement team member runs a search through the Apify Console directly and downloads CSV for immediate use, no code required
Scheduled pipeline a cron job or n8n workflow re-runs key categories monthly or quarterly, refreshing a CRM's vendor table automatically
On-demand internal tool an internal sourcing tool calls the API in the background when a user searches, so end users never need to know Apify is involved
Two-stage enrichment a broad basic run followed by a narrow enriched run against the resulting shortlist, as described above, to control cost on large category sweeps

Error handling

As with any scraping-based actor, individual runs can fail due to transient issues an unusually specific query returning no matches, or a temporary network issue on the source site. Explicitly checking for FAILED or ABORTED status rather than assuming every run reaches SUCCEEDED avoids silent failures in a scheduled pipeline going unnoticed. It's also worth logging the input parameters alongside any failure, since a query that returns zero matches often indicates a category name that doesn't quite match TopDevelopers' own taxonomy rather than an actual system failure.

Rate limits and concurrency

The maxConcurrency setting controls how many agency profiles are processed simultaneously within a single run, but if you're running multiple separate API calls in parallel say, one per domain it's worth staggering their start times slightly rather than firing all of them at once, to avoid hitting your account's overall concurrent-run limit, which varies by Apify plan tier.

Frequently asked

*Is there a sandbox for testing integration code without spending on real results? *
Running against a narrow companyName lookup for a single known agency is the practical equivalent real data, minimal cost, enough to validate your parsing logic.

*Can I run multiple domains in parallel? *
Each run is scoped to one search configuration; running separate parallel API calls for different domains works fine and is the standard pattern for broad multi-category research.

*What's a reasonable maxReviewsPerCompany for a first test? *
Something small, like 3-5, is enough to confirm the reviews array structure without spending on a full review pull across every result.

*Does the API support pagination for very large result sets? *
Use the standard Apify dataset offset/limit query parameters when fetching items rather than assuming a single request returns everything, particularly for runs near the 200-result cap.

Getting started
Full documentation and the interactive input schema are on the Apify listing: apify.com/techforce.global/it-agency-lead-finder-enricher-topdevelopers-co

For a first integration test, start with a companyName lookup against one agency you already know, confirm the output shape matches what's documented above, then move to a broader searchQuery or selectedDomain run once your parsing logic is confirmed working end to end.

How Sales Teams Are Automating Hospital and Clinic Contact Discovery

Techforce Global — Fri, 07 Aug 2026 06:33:26 +0000

How Sales Teams Are Automating Hospital and Clinic Contact Discovery

Finding a hospital or clinic's contact information isn't hard it's finding the right ones worth calling that eats time. This closing piece for the campaign covers exactly how sales teams are using scored Google Maps data to shortcut that process.

The old way

Manually searching by specialty and city, opening each listing, checking a website, noting a phone number repeated hundreds of times per territory.

The automated way

One run per category/location combination returns a lead-scored dataset with contact info already structured name, phone, address, rating, review count, and the no-website flag ready to import directly into a CRM or call sheet.

Frequently Asked

*Does this replace a CRM? *
No, it feeds one. Results export cleanly into any CRM or spreadsheet-based workflow.

Try Our Other Actors

For enrichment beyond Google Maps data, pair this with our
Website Contact Scraper. apify.com/techforce.global/website-contact-scraper-emails-phone-numbers-social-links

Getting Started

apify.com/techforce.global/google-maps-healthcare-leads-sales-intelligence-tool

Google Maps Healthcare Leads API Integrating Lead Scoring Into Your Sales Stack

Techforce Global — Wed, 29 Jul 2026 13:45:00 +0000

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/

Building a Standardized Multi-Platform Event Scraper: The Architecture Behind Smart Event Scraper

Techforce Global — Thu, 16 Jul 2026 08:00:00 +0000

Building a Standardised Multi-Platform Event Scraper: The Architecture Behind Smart Event Scraper

Event data is scattered by design. AllEvents.in, EventsEye.com, District.in, and Meetup.com each structure their listings differently different field names, different date formats, different ways of representing price and location. Pull from more than one of these sources and you inherit the reconciliation problem: matching fields, renaming columns, deduplicating, before the data is usable for anything downstream.

The Smart Event Scraper by Techforce Global is an Apify actor that solves this by running all four platforms in a single pass and returning one standardised, deduplicated schema regardless of source. This article walks through the technical decisions behind it: why a fixed category taxonomy beats free-text tagging, how the normalisation layer guarantees identical output fields, the full input/output reference, a working n8n pipeline, and code examples for calling it directly from Python or Node.

Try it: https://apify.com/techforce.global/smart-event-scraper

The Core Problem: Four Sources, Four Shapes

Each of the four source platforms exposes event data with a different shape. Dates might be ISO strings on one platform and human-readable text on another. Price might be a number, a currency-formatted string, or simply absent. Location might be a full address or just a city name. None of this is a bug in any individual platform it's just what happens when four independent systems solve the same problem differently.

The naive approach to combining them is to write four separate scrapers and reconcile the output afterward in your own code four sets of field mappings to maintain, four sets of edge cases to handle, and a reconciliation step that has to be re-run mentally every time you add a fifth source.

Why a Fixed Category Taxonomy

Free-text tags look flexible but create long-term inconsistency "tech", "technology", and "Tech & Software" all describe the same events but don't group cleanly when you're filtering across sources. Smart Event Scraper uses six fixed categories Tech & Software, Business & Networking, Food & Beverages, Health & Wellness, Art & Culture, and Education & Learning applied identically across all four platforms. A single category filter reliably returns the same type of event no matter which site it originated from. Leave category blank to pull every event type from all four sources in one run.

How It Works : Four Steps

Step 1 : Parallel source queries: each platform receives the same category, keyword, location, and date-range parameters, queried independently with per-source result limits controlled by maxEventsPerSource.
Step 2 : Field mapping: each platform's native response is mapped onto a fixed 9-field schema (title, date, location, venue, price, url, category, source, description). Fields with no equivalent on a given platform return "N/A" rather than being omitted or left null.
Step 3 : Category normalization: where a platform doesn't natively support the same 6-category system, category is auto-detected from the event title/description and mapped onto the closest fixed category.
Step 4 : Consolidation: all four sources' results merge into a single output list, each record tagged with its source platform, ready for direct import without further transformation.

Input Configuration

{ "category": "Tech & Software", "location": "Berlin", "maxEventsPerSource": 40, "dateFrom": "2026-09-01", "dateTo": "2026-09-30" }

Output Schema

n8n Weekly Event Digest Pipeline

Schedule Trigger : every Monday 9:00 AM
HTTP Request : POST to Apify API to start Smart Event Scraper with category + location + coming week's date range
Wait/Poll : every 60 seconds until run = SUCCEEDED
HTTP Request : GET results from the Apify dataset API
Google Sheets or Slack node : push results, grouped by source

Because every event record shares the same 9-field schema regardless of source, the Slack/Sheets node requires no conditional field mapping.

Frequently Asked

How do I find tech events in a specific city automatically?
Set category to "Tech & Software" and location to your target city the actor pulls matching events from all four platforms in one run.

Why does this return "N/A" instead of leaving fields blank?
So every output record is safe to import directly into a spreadsheet or database without conditional null handling.

Can I call this from a language other than Python or JavaScript?
Yes, it's a standard REST API. Any language that can make an HTTP POST request can start a run and fetch results.

Getting Started

Go to the Smart Event Scraper on Apify apify.com/techforce.global/smart-event-scraper
Click 'Try for Free' : no credit card required
Set category, location, and date range, or call the API directly using either code example above
Click Run : first results in 1-5 minutes

Actor: https://apify.com/techforce.global/smart-event-scraper
Consultation: calendly.com/techforce-infotech-pvt-ltd/intro-meeting
Website: techforceglobal.com

Playwright Bulk Website Contact Extraction Emails, Phone Numbers & Social Links From Any Domain

Techforce Global — Wed, 01 Jul 2026 13:51:41 +0000

Introduction

Bulk website contact extraction pulling emails, phone numbers, and social media links from a list of company domains is one of the most common B2B data tasks. The naive implementation using HTML parsing (Cheerio, BeautifulSoup) is fast but has a fundamental blind spot: it cannot see contact data that loads via JavaScript. The Website Contact Scraper by Techforce Global addresses this with Playwright (headless Chromium), which renders every page fully before extraction and returns a single consolidated, deduplicated record per domain with emails, phones, social links, and a transparent summary count. This guide covers the technical approach, input/output structure, and a complete n8n pipeline for automated CRM enrichment.

Why HTML Parsing Fails on Modern Websites

When a browser loads a modern website, two events happen: the server delivers the initial HTML, then JavaScript executes and renders additional content. HTML parsers like Cheerio process only the first event. Contact sections built with React, Vue, or Angular components render in the second event and are completely invisible to them.
Playwright runs a real Chromium browser, completes both events, and extracts from the final rendered DOM. This is the same approach used by enterprise contact discovery tools — applied here to bulk URL processing on Apify.

How the Website Contact Scraper Works

Step 1 : Playwright Crawler with Full JS Rendering

Each URL gets a headless Chromium browser instance. The actor waits for full page load including JavaScript execution before extraction begins. No timeout shortcuts. Full render, then extract.

Step 2 : Contact Page Auto-Discovery

From the root page, the actor scans all href links for contact-related URL patterns: /contact, /about, /team, /impressum, /kontakt. These pages are always crawled first regardless of depth position they are the highest-value pages for contact data.

Step 3 : Multi-Source Extraction

Emails: two extraction passes raw HTML attributes (mailto: links) and visible rendered text. Phone numbers: visible text only, which is more accurate for formatted international numbers. Social links: matched against platform URL patterns, grouped by platform name in the output object.

Step 4 : Consolidation Per Domain

All data from all pages crawled for a domain is merged, deduplicated, and returned as one record. Summary counts computed. scannedPages list assembled. Status set to success or no_data_found.

Input Configuration

{ "urls": [{ "url": "https://stripe.com" }, { "url": "https://notion.so" }], "maxPagesPerDomain": 10, "maxConcurrency": 5 }

Output Schema Complete Reference

n8n CRM Enrichment Pipeline 7 Steps

Google Sheets Trigger : fires when new domain URLs added to column A of your prospect sheet
HTTP Request : POST to Apify API to start Website Contact Scraper with new URLs
Wait/Poll : every 60 seconds until run = SUCCEEDED
HTTP Request : GET results from Apify dataset API
Filter : status = 'success' AND summary.emailCount >= 1
HubSpot : create or update contacts with extracted emails and social profiles
Google Sheets : write enriched data back to master sheet

The consistent one-record-per-domain output means the HubSpot node requires no conditional field mapping same schema regardless of how many pages were crawled per domain.

Getting Started

Go to the Website Contact Scraper on Apify
Click 'Try for Free'
Paste your URL list maxPagesPerDomain: 10 recommended
Enable Apify Proxy for bot-protected sites
Click Run results in 1–5 minutes depending on URL count

Actor: https://apify.com/techforce.global/website-contact-scraper-emails-phone-numbers-social-links
Consultation: https://calendly.com/techforce-infotech-pvt-ltd/intro-meeting
Website: https://techforceglobal.com

How to Scrape Quince.com Prices, Auto-Calculated Discounts, Reviews, and Images at Scale

Techforce Global — Thu, 18 Jun 2026 09:55:53 +0000

Introduction : Why Quince Data Is Worth Automating

Quince hit $2 billion in annualized revenue in February 2026 after raising a $500 million Series E at a $10.1 billion valuation. The company's manufacturer-to-consumer (M2C) model consistently prices cashmere, linen, silk, denim, and home goods at 50 to 80 percent below traditional retail a pricing strategy that has reset consumer expectations across premium essentials categories.

For e-commerce teams, brand strategists, affiliate publishers, and market researchers working in these categories, Quince's pricing movements are competitive intelligence worth tracking at scale. The challenge: Quince has no official API, no product data feed, and no bulk export mechanism. This guide explains how the Quince.com Product Scraper by Techforce Global the only dedicated Quince scraper on Apify automates data collection across three input modes and how to integrate it into an automated pricing intelligence pipeline.

Three Input Modes When to Use Each

Mode 1 : Fuzzy Keyword Search
The fuzzy_search mode runs your keyword against Quince's search interface. Use this for cross-category research where you want all products of a type regardless of their location in Quince's hierarchy. 'Cashmere' returns results from Women, Men, and Home simultaneously.

{ 
    "mode": "fuzzy_search", 
    "searchQuery": "mongolian cashmere crewneck", 
    "searchLimit": 50, "region": "US" 
}

Mode 2 : Category Browse (300+ Categories)
The category dropdown is built from Quince's live mega-menu, not a static list. New categories Quince adds to their navigation appear in the actor automatically. Navigate to Women > Sweaters > Cashmere or Home > Bedding > Linen with a single dropdown selection.

{ 
    "mode": "category", 
    "category": "/women/sweaters", 
    "categoryMaxProducts": 200, 
    "region": "US" 
}

Mode 3 : Direct Product URLs
The product_urls mode accepts a list of specific Quince product page URLs for precise, repeatable monitoring of competing SKUs on a weekly schedule.

{ 
    "mode": "product_urls", 
    "productUrls": [{ "url": "https://www.quince.com/women/lightweight-cotton-cashmere-dolman-sleeve-sweater" }], 
    "region": "US" 
}

Complete Output Schema Twelve Fields

Why Auto-Calculated Discount % Matters at Pipeline Scale

Most product scrapers return two price strings and leave the calculation to the consumer of the data. At 50 records this is a minor inconvenience. At 2,000 SKUs tracked weekly across five categories, it is a transformation step that must be built, tested, and maintained indefinitely.

The Quince.com Product Scraper returns discount: '49.5%' as a first-class output field. This eliminates the transformation step entirely: sort by discount immediately, filter in n8n where discount > '40%', display on an affiliate site without a formula, compare month-over-month exports without preprocessing.

Primary-Color Images Why the Filtering Matters

Quince products come in multiple color variants. A naive scraper returns all variant images for a cashmere crewneck available in 12 colors with 3 photos each, that is 36 images per product. The Quince.com Product Scraper returns only the primary-color hero images: the images that appear by default when a shopper first arrives on the product page. Clean, immediately usable product imagery without a deduplication step.

n8n Automated Pricing Intelligence Pipeline Step by Step

Schedule Trigger : runs every Monday at 8:00 AM IST
HTTP Request : POST to Apify API to start the Quince Scraper (mode: category, /women/sweaters, max 200, region: US)
Wait/Poll node : checks every 60 seconds until Apify run status = SUCCEEDED
HTTP Request : GET request to Apify dataset API to fetch all product records
Filter node : filter records where discount field is NOT equal to 'N/A' (actively discounted products)
Google Sheets node : append all discounted products to weekly pricing tracker with timestamp
Filter node (second pass) : filter where discount value is greater than '40%'
Slack node : post top deals to #pricing-alerts channel: title, sellingPrice, retailPrice, discount, URL

Practical Use Cases With Example Inputs

Use Case 1 — Weekly Category Benchmarking

Input: 
    { 
        "mode": "category", 
        "category": "/women/sweaters", 
        "categoryMaxProducts": 200 
    }

Schedule: Every Monday 8AM
Result: Complete cashmere sweater catalog with current prices and discount % → append to tracking sheet → compare week-over-week

Use Case 2 — Affiliate Deal Newsletter
Filter: discount > 45% from any category sweep
Output: Top deals with title, sellingPrice, discount, averageRating, productUrl → format for newsletter template
No manual calculation required discount field is already there

Use Case 3 — Competing SKU Monitoring

Input: 
    { 
        "mode": "product_urls", 
        "productUrls": [25 specific competing Quince URLs] 
    }

Schedule: Every Sunday night
Output: Current prices and review scores for each SKU → flag where Quince discount > 30% → inform your own pricing response

Getting Started

Go to the Quince.com Product Scraper on Apify
Click 'Try for Free' — Apify provides free trial credits, no card needed
Select mode, configure input, set limit and region (US or CA)
Click Run — export as JSON, CSV, Excel, or RSS — or connect via Apify API to n8n

Actor: https://apify.com/techforce.global/quince-scraper

Consultation: https://calendly.com/techforce-infotech-pvt-ltd/intro-meeting
Website: https://techforceglobal.com
Email: bhavin.shah@techforceglobal.com