Direct answer: Use a Manual Trigger and n8n's HTTP Request node to call Apollo's saved-contact search endpoint with an API key stored in credentials, split the returned contacts into items, normalize the approved fields, then look up each Apollo ID in Airtable. Update an existing row when the ID matches and create a new row only when it does not. Keep the first version manual and capped; do not connect it to an email sequence.
Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.
What this workflow does
This pattern copies a controlled set of contacts that already exist in the team's Apollo workspace into an Airtable review table. It preserves the Apollo contact ID as the stable external key and records the import run for traceability.
It does not search the full Apollo people database, promise email or phone availability, judge contact quality, enrich missing data, or authorize outreach. Apollo access, fields, credits, and API permissions still depend on the account.
Workflow map
Apps and nodes
Manual Trigger
Require a person to start the pilot import.
Configure: Keep the first version manual so filters, fields, and record counts can be reviewed before scheduling.
HTTP Request: Apollo
Call Apollo's saved-contact search endpoint.
Configure: Use POST /api/v1/contacts/search, put the API key in an n8n credential or protected header, and start with a small page size.
Split Out
Turn the returned contacts array into one n8n item per contact.
Configure: Keep the Apollo contact ID and only the fields approved for the Airtable base.
Edit Fields
Normalize names, company, title, source, and review status.
Configure: Do not invent unavailable email or phone values. Store blank as blank and keep source timestamps when provided.
Airtable lookup
Find an existing row by Apollo contact ID.
Configure: Use a dedicated Apollo ID field as the primary external key rather than matching only on name or company.
Airtable create or update
Upsert the normalized record without duplicating an existing Apollo contact.
Configure: Create on no match; update only the approved fields on one exact ID match.
Run summary
Show how many records were created, updated, skipped, or failed.
Configure: Keep counts and IDs, not a broad copy of personal contact data in execution logs.
Step-by-step logic
01. Define the Airtable review schema
Create fields for Apollo contact ID, name, company, title, approved contact fields, source, import date, and review status. Decide which fields n8n may update on later runs.
02. Create the Apollo credential
Generate or select an Apollo API key with the minimum access needed, store it in n8n credentials, and test access separately. Never paste a real key into a Set node, expression example, or exported template.
03. Request saved contacts
Call the saved-contact search endpoint with a narrow keyword or other approved filter and a small page size. People Search is a different job and can return net-new people rather than contacts already saved by the team.
04. Split and normalize the response
Turn the contacts array into individual items. Map Apollo ID first, then copy only the fields needed for review. Preserve empty values instead of filling them with guesses.
05. Look up by Apollo ID
Query Airtable using the external ID. A match on name alone is unsafe because names change and are not unique.
06. Create or update
Create a row when there is no exact Apollo ID match. Update the approved field set when one exact match exists. Send multiple matches or malformed IDs to review.
07. Review the run before scheduling
Compare created, updated, skipped, and failed counts with the Apollo result page. Keep the workflow manual until pagination, field ownership, and duplicate behavior are understood.
Configuration examples
These examples use placeholders. Map them to the fields and credentials in your own n8n account.
Apollo request
POST https://api.apollo.io/api/v1/contacts/search
Header: x-api-key = stored credential
Body: { q_keywords: "approved segment", page: 1, per_page: 10 }
Use a filter that refers to an owned, reviewed contact set. Confirm account access before relying on the endpoint.
Airtable external key
Apollo Contact ID = {{apollo_contact_id}}
Treat the ID as text and require an exact match.
First-run guardrail
Manual Trigger + per_page: 10 + no email-sequence node
A small manual batch makes field and duplicate mistakes visible before scheduling.
Run result
created: 6 | updated: 3 | skipped: 1 | failed: 0
Store counts and record IDs; avoid copying unnecessary personal data into a summary channel.
Common problems
Apollo returns 401 or 403
Likely cause: The key is missing, invalid, lacks endpoint access, or the account does not meet the endpoint requirement.
Fix: Test the key with Apollo's official instructions, confirm account and endpoint access, and keep the failure visible instead of retrying indefinitely.
The response has people you did not expect
Likely cause: The workflow uses People Search instead of the saved Contacts search endpoint, or the filter is too broad.
Fix: Use the endpoint that matches the reader job and start with a narrow reviewed segment.
Airtable creates duplicate people
Likely cause: The lookup matches on name, email alone, or a field that is empty in some records.
Fix: Use Apollo contact ID as the external key and route missing IDs to review.
A later run overwrites reviewed Airtable fields
Likely cause: The update node writes every mapped field regardless of ownership.
Fix: Define which fields Apollo owns and update only that allowlist; keep Airtable-only review notes untouched.
Only the first result page is imported
Likely cause: The workflow has no explicit pagination loop or stopping rule.
Fix: Prove one small page first, then add bounded pagination with a maximum page/record guard and a recorded stop condition.
Ways to extend it
- Add a reviewed pagination loop with an explicit maximum record count.
- Create a separate reject table for missing IDs, multiple Airtable matches, or malformed fields.
- Add a human approval field before any contact moves from research to outreach operations.
- Write a last-synced timestamp and source hash when change detection is more useful than unconditional updates.
Limits of this reference
- This is a reference architecture and was not tested end to end by FloxoLab.
- Apollo API availability, fields, permissions, and rate limits can vary by account and endpoint.
- Moving a contact record does not prove accuracy, consent, deliverability, or permission to contact that person.
- No external messages or Apollo sequences are part of this workflow.
Official sources
- Apollo API overview
- Apollo API authentication
- Apollo search for saved contacts endpoint
- n8n HTTP Request node
- n8n Airtable node
n8n partner link
Build this workflow in n8n Cloud
Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.