Apollo.io phone number scrapping confusion using make.com

[Tanishq_Agarwal]

Hi Make.com Community,

I’m building an automation to scrape employee phone numbers using Apollo’s API, but I’m facing a challenge with webhook response matching. Looking for advice from anyone who has worked with asynchronous APIs in Make.

My Workflow Structure:

Scenario 1: Main Data Processing

1. Google Sheets Module - Read company details from my dataset [Screenshot: Google Sheets trigger showing company data]

2. HTTP Module - Call Apollo People Search API to find directors/co-founders for each company [Screenshot: HTTP module configuration for People Search API]
   

   

3. Google Sheets Module - Add found employees to employee data sheet

4. HTTP Module - Call Apollo People Enrichment API with reveal_phone_number: true and webhook URL pointing to Scenario 2 [Screenshot: HTTP module for People Enrichment with webhook parameter]
   

   
   
   
   

5. Repeater - Process next company in the dataset

Scenario 2: Webhook Handler

1. Custom Webhook Trigger - Receive phone number data from Apollo [Screenshot: Webhook trigger setup]
2. Google Sheets Module - Update the employee sheet with received phone number [Screenshot: Update row module configuration]

The Problem I’m Facing:

Apollo’s phone number enrichment works asynchronously - it takes several minutes to verify and return phone numbers via webhook. This creates a timing mismatch:

• Scenario 1 processes 50-100 people quickly (sending API requests)
• Scenario 2 receives webhook responses randomly over time

• I can’t match which phone number belongs to which person!

My Questions:

• API vs Website Data Consistency: If I can see a phone number for a person on Apollo’s website, will I definitely get that same phone number through the API in Make.com? Or is there no guarantee of consistency between what’s shown on the website interface vs what the API returns?
• Webhook Response Matching Chaos: I’m worried about a major workflow mess-up. My first scenario will process people quickly (sending requests fast), but webhooks will arrive minutes later randomly. Won’t this create chaos where I can’t tell which phone number belongs to which person or Make will handle it itself?
• Processing Order Issues: Will webhook responses arrive in the same order I sent the requests? Or could Person A’s request be sent first but Person C’s webhook response arrive first? How does Make handle this timing mismatch?
• Webhook Queue Handling: When my second scenario receives multiple webhook responses over time, will they get processed in proper order, or will there be a mess-up in the flow? Does Make queue these properly or do they interfere with each other?
• Investment Risk: Since I haven’t invested in Apollo’s paid plan yet, I want to know - has anyone actually successfully gotten phone numbers through Make that they could see on Apollo’s website? Or is this just theoretical and doesn’t work reliably in practice?

Technical Details:

• Using Apollo People Search API for finding employees
• Using Apollo People Enrichment API for phone numbers
• Both APIs consume credits from Apollo plan
• Phone numbers visible on Apollo website, but not sure if API returns same data

Any advice, experiences, or alternative approaches would be greatly appreciated! Has anyone successfully implemented a similar asynchronous webhook matching system in Make?

Thanks in advance!

[nodeai]

The best approach here is to log the person_id when sending the enrichment request and use it to match the webhook response when it arrives.

In the webhook JSON, this ID is typically found under the people array like this:
“_id”: “value” (the one with underscore before id is the person ID)

This same person_id is also returned in the initial People Search or Enrichment API response. By storing it alongside your data (e.g. in Google Sheets), you can accurately match each asynchronous webhook response to the correct person record later on.