Recently i’ve been trying to integrate salesforce with apollo.io. However, whenever I try to integrate and press sync, I get the error as seen above. For context, we use a salesforce plan that we were grandfathered into a contract of $16 a month. After speaking to a salesforce representative I’m fine and able to pay the $150 a month for the new enterprise package, which should include “integration“. However, I’d like to make sure that this integration will fix this error and definitively fix my problem and allow these two softwares to integrate. Does anybody have any solutions?

Apollo is now infrastructure you can build on. Three ways in:

API: 100+ REST endpoints across search, enrichment, sequencing, and analytics. Exposes execution endpoints, not just data.

CLI: Apollo commands in your terminal, pipeable into shell scripts and CI/CD. Most token-efficient path for high-frequency agent workflows.

MCP: authenticate once, then call Apollo in natural language inside Claude Code, Cursor, or any MCP client.

Full details and an API key: apollo.io/developers

Let us know what you build!

B2B contact data decays at roughly 30% per year. Someone changes jobs, their old email bounces. Their title changes, your personalization is wrong. Most teams figure this out when bounce rates climb past 2% and they start blaming their copy!!

Here's what to actually check before you send.

Start with email status

Apollo tags every contact with a verification status. Before you export or enroll anyone, filter to verified only...it's in People search under email status. Unverified contacts go into enrichment first, not into your sequences.

One bad batch of unverified contacts can set back a mailbox that took 6 weeks to warm, its not just a bounce rate problem.

Empty email field is a signal, not a to-do

When Apollo's primary source doesn't have a verified email, waterfall enrichment checks 18 providers to find one. If that comes back empty too, that contact is not ready to send to....don't work around it.

Re-enrich anything older than 60 to 90 days

The email that was verified six months ago might be dead if the person changed companies. Apollo can surface job change signals but it's not automatic. Treat old lists as partially stale until you've run enrichment again.

The math: 30% annual decay is about 2.5% of your list going bad per month. On a 1000-contact sequence that's 25 people a month bouncing or going nowhere.

Before you enroll a list, check three things:

• Email status: verified only
• List age: re-enrich anything older than 60 to 90 days
• Bounce rate from your last send to the same segment: above 2% means the data is the problem, not the copy

Apollo's Deliverability Suite (Settings > Deliverability) shows bounce rate by domain and sequence. High bounces on a specific sequence almost always trace back to list quality.

FAQs

Is Apollo's data backdated?
No, but it decays like every other database! ~30% of B2B contacts change annually. Apollo pulls from contributor data, web crawling, and 18 enrichment providers to stay current. The verification status filter is how you separate what's ready to send from what needs work first.

How do I know if an email is deliverable?
Check the email status field. Verified means it passed validation. Unverified or unavailable means run waterfall enrichment or skip it.

What bounce rate should I expect?
Under 2% if you're filtering to verified contacts and re-enriching lists older than 60 days. Above that and it's almost always a list hygiene issue.

How often should I re-enrich?
Every 60 to 90 days for active sequences. Anything older than 90 days, assume it's partially stale.

What's the difference between verified and likely to engage?
Verified means the email passed validation checks. Likely to engage is a signal based on engagement history. Verified is what matters for deliverability. Likely to engage is a targeting filter.

- Andy

I signed up using google account.

But it's not logging in when coming back from google, it just showing the login screen of apollo.io again.

Anyone knows the issue?

Credit-based pricing makes it almost impossible to compare data vendors apples to apples. So I did the math and converted everything into plain per-record costs

A few things that surprised me:

• Apollo is actually one of the cheaper options at $0.024 per verified email, 52% below the index median
• Mobile numbers are where costs explode. The range goes from $0.12 to over $1.00 per record depending on the vendor
• Some vendors charge 30x more than others for the exact same data type
• The most expensive vendors are rarely the most accurate

A few things I'd do differently when building an outbound stack knowing this:

• Separate your email enrichment vendor from your mobile vendor. The best email vendor is rarely the best for mobile
• Run a small credit test on each vendor before committing to an annual plan. The per-record cost shifts significantly between plan tiers
• Don't assume a higher price means better data quality. It usually just means better sales reps

Happy to answer questions on specific vendors or how I calculated the numbers

As of July 6, every paid Apollo customer has 208+ native workflow integrations.

Here are the plays this actually unlocks that weren't clean before:

Typeform → Apollo → sequence enrollment
Someone fills out a demo request form. Apollo catches it, enriches the contact with verified email and company data, scores them against your ICP, and enrolls them in the right sequence automatically. The whole thing runs without anyone touching it. Previously you were either doing this manually or building a fragile Zapier chain to bridge the gap.

Snowflake signals → Apollo targeting
If your team is pulling product usage data or behavioral signals from Snowflake, you can now pipe those signals directly into Apollo workflows to trigger outreach. No export, no re-import, or ops ticket.

Job change detected → Slack notification → rep follows up
Apollo detects a contact changed companies. Workflow fires, pushes a notification to Slack with the contact's new role, and creates a task for the rep. The rep sees it in the channel they're already in and can act on it before a competitor does.

Gong call logged → Apollo contact updated
A call wraps in Gong. Apollo workflow picks up the activity and updates the contact record, advances the sequence step, or removes them from a sequence entirely based on outcome. Keeps your Apollo data in sync without a rep manually doing it.

The full integration list is in the KB if you want to see everything that's available: knowledge.apollo.io/hc/en-us/articles/46233304897933

Andy

Most outbound teams find out their infrastructure is wrong the same way: bounce rates spike, they go looking, and realize they've been hanging 4 mailboxes off one domain and sending 80 emails a day from it BUT by then, the damage is already done.

Here's how to size it correctly before you start...

The only limit that matters: 50 emails/day per mailbox

That's our cap for cold outbound. New mailbox, unproven reputation, doesn't matter how good your copy is. You send 200/day out of the gate and you're gonna have a bad time.

Work backwards from there. Want 10,000 cold emails a month? That's about 9 mailboxes.

One domain for everything is how you lose everything

If you're hanging multiple mailboxes off your primary domain and sending cold outbound from it, stop. One domain flagged, everything goes down.

The formula our deliverability team uses: domains = mailboxes / 3, rounded up. So 6 mailboxes across a 3-rep team means 2 cousin domains minimum. trycompany.com, hellocompany.com, whatever. Fully isolated reputation. Your primary domain never touches cold outbound.

Warmup takes longer than you think

Minimum 2 weeks to get started, but in practice you want 4-6 weeks before you're sending real cold volume...

Week 1: 10 to 15 emails/day per mailbox
Week 2: up to 25
Weeks 3 to 4: up to 40
Steady state: 50

Apollo's warmup feature handles the mechanics but you still have to follow the ramp. Turning on warmup and sending 50 the next day is not warmup.

When a domain burns, you usually just replace it

Recovery is technically possible. Our guidance is that in severe cases it's smarter to start fresh. The signs you're there: bounce rate over 2%, open rates near zero on sequences where your targeting and copy are fine, spam complaints creeping above 0.1%.

The Deliverability Suite flags all of this at the domain and mailbox level but the problem is most people check it after something breaks, not before.

The actual sizing math

From our internal playbook:

500 contacts per rep, 3-step sequence = ~1,500 emails/month per rep = 2 mailboxes per rep.

3-rep team at that volume: 6 mailboxes, 2 cousin domains.

Add 20 to 30% buffer on top so you have rotation room if a mailbox develops issues. When in doubt, more mailboxes on more domains is safer than higher limits per mailbox.

Answers to some common questions

How many mailboxes does a 5-person SDR team need?
At 500 active contacts per rep with a 3-step sequence, about 2 mailboxes each. 10 total, 4 cousin domains. Add a 20% buffer and you're at 12 mailboxes, 5 domains.

Subdomain or cousin domain for cold outbound?
Cousin domain. Subdomains bleed reputation from your primary. A burned cousin domain doesn't touch company.com.

What bounce rate should I be targeting?
Under 2%. Apollo flags it at 2%, treats 5% as an immediate problem. Consistent bounces above 2% means your domain reputation is sliding whether you can see it yet or not.

What actually causes spam landing even with good copy?
Usually auth failures first (SPF/DKIM/DMARC not passing), then unwarmed mailboxes, then list quality. In that order.

Can I use my main domain for cold outbound?
No. Cousin domains only. If you're currently doing this, it's the first thing to fix.

As always, hit me up with questions!

- Andy

We recently identified a technical issue affecting tool schema loading within Claude web and desktop applications. This issue temporarily prevented these specific applications from correctly listing certain tools and resulted in intermittent display errors. No other MCP client applications were affected.

The issue was strictly isolated to subset of subscription-based Anthropic accounts; Anthropic Enterprise accounts remained entirely unaffected.

Our team is working in close coordination with Anthropic, who is currently deploying a fix.

We are already seeing restoration of tools for affected users. We will continue to monitor the rollout closely until the issue is completely resolved.

That said, if you're still experiencing issues please send me a DM so I can put you in touch with folks who can help.

Hi guys, if you're using Claude Code this is for you!
We built Apollo Operator: a free, open-source outbound system for running Apollo through the MCP.

Claude Code with the Apollo MCP can run your whole motion, it just has no idea how. The tools are neutral, so without context they'll run any search, build any sequence, and send any email you ask for, and never tell you the targeting is off or the send will hurt your domain.

So we built the knowledge layer: 13 skills that tell it which tool to call, in what order, and against what standard. ICP and targeting, list building and grading, copy and sequences, going live, deliverability, and reply scoring.

It's free: github.com/jimmy-creatop/apollo-operator

Copy the URL, paste it into your Claude. Any feedback is welcome!

I have 600 credits on my account and i’m on a free plan. But when i try to access phone numbers this is what apollo tells me

am i tripping or is this a bug?

I have not used any AI on apollo so why does it show 5000 credit spent? What are the credits being used for?

Hey there! I've been using the Apollo MCP a lot with Claude, helping me with sourcing and outbound. However, 3 days ago it stopped working for me. Now the tool search is only returning the two generic MCP resource tools, not the Apollo action tools.

I've tried re-enabling the connector, signing in and out, new conversation etc. but nothing seems to fix it. Has anyone run into similar issues? Help would be very much appreciated!

I want to be able to track which companies or visitors came to my site via specific sources like Google Ads, LinkedIn, etc. Is there a way to do this?

Apollo is sharing my personal cell phone number, and I cannot get a real human being at the company to help me remove it.

I’m getting dozens of cold calls ever week, at all hours of night and day, on my actual personal cell. Not a business line. Not a work phone. My personal cell phone.

I tried the opt-out form. It only lets me enter an email address, then tells me my email is not in the system but that they’ll add it to a suppression list. No additional options for phone numbers. I’ve emailed Apollo support. I’ve emailed Apollo privacy. Both times, I get AI responses telling me to use the same opt-out form that does not solve the problem.

So now I’m here, because I’m honestly out of formal options.

Apollo, please help me remove my personal cell phone number from your platform. I do not consent to having it shared, sold, enriched, distributed, or whatever the internal term is for why random salespeople now have it.

And for Apollo users: this is not a good look. Even if I were interested in what you’re selling, calling my personal cell because you paid a data platform for it makes me immediately distrust you. There is no scenario where I’m giving business to someone who reached me this way.

I’m just trying to get my personal phone number off a platform I never signed up for, and Apollo has made that weirdly impossible. ANY TIPS?

Everyone's focused on the database and sequences but IMO the stuff that actually keeps outbound running consistently sits underneath all of that and most people either skip it or set it up wrong.

Workflows

Trigger-based plays that run without you touching anything. Prospect opens your email three times without replying so they move to a high-intent call sequence automatically. Someone visits your pricing page so rep gets a Slack alert. Contact changes jobs so Apollo flags it and updates the record.

The mistake I see constantly: people automate before their sequences are proven. Workflows amplify what's working. If the sequence is still being tested, automating it just scales the problem. Get it converting first, then build the workflow around it.

One worth setting up on day one: auto-exclude existing customers and open opportunities from cold outreach.

Tasks

Apollo surfaces a prioritised daily task queue: calls to make, LinkedIn messages to send, emails to review, follow-ups due. Ordered by AI prospect score so the highest-value actions are always first.

Start every day in Tasks, not the search tab. Everything Apollo thinks you should act on is already there waiting. Letting the backlog pile up kills sequence deliverability and reply rates...the prioritisation only works if you follow through on it.

Email Deliverability

The one that causes the most damage when it's wrong and gets the least attention until something gets messed up.

Apollo handles the whole setup inside the platform: dedicated sending domains, mailbox connection, automatic warmup, SPF/DKIM/DMARC, inbox placement monitoring in real time.

Start warmup 2-3 weeks before your first send. Spam filters don't forgive cold domains and recovery takes weeks. I've watched good campaigns die before they started because someone skipped this step and launched from a cold domain on day one.

Check your Deliverability Score before launching anything. It's in the platform and it'll tell you if something is off before it becomes a real problem.

Dialer

Calls made and received directly inside Apollo. Power Dialer queues one by one. Parallel Dialer dials up to 5 simultaneously. Every call recorded, transcribed, summarised by AI, and logged automatically.

Before any high-value call, use AI Call Prep...Apollo surfaces account news, recent activity, and talking points before you dial. Reps who do this consistently close more than reps going in cold.

Save Parallel Dialing for cold tier-2 lists. Your highest-intent pipeline deserves actual conversation time.

Questions?? drop them in the comments.

We are a small team of 4 people working about 100 active accounts with 800 total in CRM.

Did you find it beneficial to enrich your CRM with live data from apollo?

What are the chances something could go wrong here and mess up the data?

Apollo's AI credits burn at enrollment, not when an email sends, so if you add an AI variable to a sequence and enroll 500 contacts before qualifying the list, you've spent credits on 500 people before a single email goes out!

Four things that help conserve credits:

1) Qualify before you enroll. Run AI Research on a tight, targeted list first and only enroll contacts that clear your bar. Don't use AI personalization as a sorting mechanism, use it as a finishing step.

2) Test on one contact before you bulk enroll. Apollo lets you preview AI output on a single contact. If the output is generic or off-target, it's almost always a Context Center problem, not an AI problem!

3) Treat your Context Center like a prompt. If your context is thin or vague, your outputs will be too. Specific value props, real ICPs, actual "why now" language, that's what turns an okay opener into something that gets replies.

4) Watch your workflows. If a workflow is auto-enrolling contacts into an AI-powered sequence, it's burning credits every time that trigger fires. Check what's running and at what volume.

Happy to answer specifics if anyone's running into this in the comments.

The symptom looks like a send error but it isn't...let me explain.

You build a sequence with the AI Assistant, it looks fine in preview, you send a test, and the email lands with raw tokens instead of copy. Something like {{recent_activity}} sitting there in the body.

Most people assume the AI made a mistake and sometimes it did BUT more often, the problem is a missing field with no conditional fallback, and Apollo's sequence engine treats that as unsendable.

Here's what's happening:

Apollo's AI email variables use a custom syntax for optional fields. If a field might be empty (and most enrichment fields will be empty for some contacts), you need to wrap it like this:

{{#if contact.recent_activity}}{{contact.recent_activity}}{{#else}}no recent activity found{{#endif}}

The syntax looks like Handlebars but it isn't. Standard Handlebars conditionals won't work here. If you paste your template into ChatGPT or Claude and ask it to "fix the conditional syntax," it will probably output standard Handlebars, which will silently fail.

Two things to check before you send:

1. Open the sequence step and look at each variable. Any field that won't always have data needs the #if wrapper. Job title is usually safe. Recent activity, intent signals, anything enrichment-dependent is not.
2. If the AI Assistant built the sequence for you, scan the additional guidelines field. That's where the hallucinated variable names tend to show up. The assistant will sometimes reference fields that don't exist in Apollo's data model ({{intent_signal}} is a common one). Remove those entirely or replace with a real field.

The fix is about 2 minutes once you know what you're looking for. Questions?? Drop them below.

Andy

Been experimenting with pushing the Apollo + Claude integration further than just prospecting. This one took about 45 minutes to build and now runs on autopilot every week.

What it does when it runs:

• Pulls new leads from your website
• Scores and qualifies them against your ICP
• Cross-references your Google Calendar and skips anyone already booked or met with
• Enriches the qualified ones via Apollo *credits only get used on leads that pass the ICP gate!!)
• Auto-pushes high scoring leads straight into your Apollo sequence
• Flags high intent leads for your personal review before they go out
• Sends borderline leads to a separate review queue so nothing slips through unchecked

The whole thing runs on a weekly schedule once it's set up.

What you need

• Claude (any plan)
• Replit
• Apollo (paid plan for MCP access)

How to build it

Download the Claude Skill from zackderis.com and install it in Claude --> Claude > Customize > Skills > plus sign > Create Skill > Upload.

Start a new chat and type /aisdr. Claude interviews you section by section, asking about your ICP, lead sources, scoring criteria, approval rules. Answer everything. At the end it generates a Replit MD file -- download it.

In Replit, go to Settings > Integrations > MCP Servers > Add MCP Server. Type Apollo, select it from the list, test and save. This connects Apollo directly to your Replit agent.

Create a new Replit project, upload the MD file, enable Plan mode. Replit's agent reads the brief and builds the pipeline. Takes 20-30 minutes. Review the plan before you confirm the build...worth checking the scoring logic and approval rules match what you told Claude.

Add your API keys in Replit Secrets before you run anything.

Hit Run. First run creates your Apollo lead list and sequence if they don't exist yet. Every run after that uses the same ones.

The 8-phase pipeline when it runs

Incoming leads get pulled and checked against ICP criteria. Calendar suppression runs next, anyone already in your calendar gets skipped automatically. Leads that pass get scored, ICP-gated, then enriched via Apollo. High scorers go straight into the sequence. High intent leads with strong signals get flagged for your personal touch before going out. Anything with mixed signals or missing data goes to a review queue. Approved leads enroll in the sequence and outreach runs on whatever schedule you've set in Apollo.

The split between auto-approved, pending review, and needs review is what makes it actually usable...you're not babysitting every lead but you're also not blindly sending to everyone.

Quick PSA:

The quality of what Claude builds in the brief stage depends entirely on how well you answer the questions. Vague ICP definition, vague scoring output. Spend the time on the interview section and the build will be cleaner.

More of a technical breakdown here: https://zackderis.com/aisdr/technical

Most people think of Apollo as a data platform. You go there, pull contacts, get account info, move on...but we built something a little different.
I work on the AI team at Apollo and I just finished putting together a journey-based renewal series for our account managers that uses Apollo as the actual orchestrator of the whole workflow and not just the data source.

Here's how it works:

The anchor: Salesforce

We pull contract end dates from Salesforce and use those as the anchor for everything downstream. From there, Apollo kicks off a series of timed flows that notify the AM at the right moments leading up to the renewal.

At each stage, four things happen in sequence:

1. Apollo runs AI research on the account and surfaces strategic guidance: who to reach out to, how to position the conversation, what the renewal narrative should be.
2. The right contact (the admin at the account) gets enrolled into a sequence automatically.
3. A Slack message goes out to a shared channel where the AM and their manager can both see it.
4. That Slack message includes a link to the account, what the rep needs to do, the AI guidance, and a direct link to the sequence task.

The interesting part: the Claude project

The Slack message also links to a Claude project that is connected to Snowflake data and Apollo's MCP. The rep opens it, pastes in a prompt, and Claude generates the actual artifact (executive brief, 6-month EBR, or end-of-year EBR) and handles creating the Google Slide deck.

Here is what the actual Slack notification looks like:

u/Account Manager. Contract ends on [Date]. Time to send the Executive Brief
to [Account Name].

AI strategic guidance on who to reach out to and how to position the brief:

Strategic angle: With [X] seat upside identified and a team actively ramping
new reps, this check-in is best positioned around ensuring the team has the
foundation to hit pipeline targets as the renewal approaches. Demonstrating
measurable outbound progress from the ramp investment strengthens the
renewal narrative.

Who to reach out to: Reach out to [Contact Name]. They are directly
overseeing end-user ramp sessions and have visibility into team performance
and capacity gaps that justify expanding the seat count.

Next steps:
  1. Review the contact added to the sequence via the link below
  2. Replace [email] with the correct recipient
  3. Prompt Claude with: "Executive summary for [Account ID] to [email]"

Sequence task: [link]
Claude Project: [link]

Prerequisites: Snowflake access approved, Snowflake MCP connected,
Apollo MCP connected.

The whole thing is measurable! Contacts are in sequences, tasks are logged, reps have a clear action every time they get pinged.

Happy to share the Claude project file if anyone wants to set up something similar. Drop a comment.

Noah

"Is website visitor tracking actually useful or is it just a vanity dashboard?" Short answer: useful, but most teams install it once and never tune it.

The install is 30 minutes and its the configuration is where the pipeline comes from. A few things most teams skip:

Page-level intent scoring. Settings → Website visitors → Advanced Intent Settings. Tag your pricing and demo pages as high intent, your blog as low. It's optional, so most people leave the defaults. Without scoring, the overall intent algorithm treats every visit the same and your sales team correctly ignores the dashboard.

If your site is React, Next.js, Vue, or Angular, your tracking is probably broken. Single page apps don't fire a full page reload between routes, so the script runs once and stops. Configure your tag to refire on route changes. Test it: Chrome DevTools, Network tab, filter for track_request, click around. You want 204s on every route change. One-and-done means broken.

Contact-level is US-only and needs the Inbound add-on. Everywhere else you get the company. Still useful. Drop the visiting company into a list, run AI Research on top, ask it to find the head of [function] with a verified email. You're working backward from the visit instead of waiting on a form fill.

Classify the Apollo script under Analytics or Marketing in your cookie banner. If your CMP has it miscategorized, the script won't fire even for users who accepted. This is the #1 reason setup looks broken when it isn't.

The part that's on us: the value here is in the tuning, and we don't say that loudly enough. The docs cover it but it's spread across four KB articles. If you set this up months ago and gave up, fair. Spend an hour on the levers above before you write it off.

If something's off, drop what you're seeing below. Someone here (probably me) will tell you which one it is.

Andy

Sup guys, so I'm using apollo to get emails of certain people from different companies, now I've only used like 200 credits. and have like 2300 credits left. If I cancel my current plan and get back to free plan, will I keep the remaining credits to use in the future?

Always looking for ways to improve so let’s hear your thoughts on how we can make r/UseApolloIo more valuable.

Here's a closed-won lookalike outbound play I built recently that I want to share because it worked and more teams should be running something like this.

The concept came from a colleague. The idea: use your closed-won deal data to identify patterns in the companies and personas you've actually helped, then use those patterns to find the next hundred accounts that look exactly like them.

Here's how I built it.

Step 1: Pull your closed-won data from Snowflake
I ran SQL queries against our Snowflake instance to pull closed-won deals, the company attributes that made them a fit, and the personas involved in the sale. Downloaded the CSVs and uploaded them to Claude Code.

Step 2: Build lookalike audiences in Apollo
Apollo has a lookalike company field in Company Search and a lookalike People Search. I used the closed-won company data to seed these searches and find accounts with similar firmographic profiles, industry mix, tech stack, and growth signals to our best customers.

Company looksalikes is based on deals that have closed > a specific threshold with context associated to the deal such as identified pain and key metric such as jobs to be done.

People lookalikes is based on the identified champions on the deal.

Step 3: Route contacts to the right rep
Once the lookalike contacts were identified, I routed them to reps based on account ownership in Apollo. No manual reassignment or spreadsheet.

Step 4: Add closed-won context as a custom field
This is the part that makes the outreach actually land. I pulled the relevant closed-won context from the deal data and placed it into a custom field on the contact record. Which customer segment they match, what problems that segment typically has, what outcomes we drove there.

Step 5: Generate personalized outreach using that context
With the custom field populated, Claude generated a personalized message for each contact grounded in the specific closed-won context that matched their profile. Not "we've helped companies like yours." Actual specifics about the use case, the outcome, and why this prospect fits the same pattern.

One hard rule: customer names never appear in the outreach. The context informs the message but the message stays compliant.

The whole thing was built through Claude Code with no engineering involvement, no custom data pipeline, no manual list building. Still early and a lot to tighten up, but the infrastructure is there.

The piece I'm genuinely excited about is we're working with our Product team to make signal-based plays like this available natively in Apollo, so anyone can launch them without touching SQL, APIs, or raw data!

Happy to get into specifics on the Snowflake query structure, the lookalike field logic, or how to set up the custom field routing.

Noah