Apollo Account Audit (Foundations)

Before you run anything on an Apollo account you did not build, find out what state it is in. This skill checks the account with reads only and hands back graded findings. It changes nothing: every fix waits for the operator.

It exists because accounts drift quietly. A sequence can sit active for weeks sending nothing, cold email can go out from the company's primary domain, and a website tracker can be installed without ever receiving data, and none of it shows up until someone goes looking. On the first real account this was run on, it found all three in under an hour.

When to use

• Taking over an existing Apollo account, your own or a client's.
• Onboarding a client account through a partner seat, before touching anything.
• "Why isn't this campaign sending?"
• Quarterly, as a standing health check.

The checks

Run them in this order, since the early ones explain the later ones. Grade each area Good, Watch, or Fix.

The finding that looks like a performance problem and is not

A sequence can be active, with contacts enrolled, and send nothing, because its touches are not approved. Verified 2026-09-14: an active sequence with 5 enrolled contacts had scheduled zero emails in two weeks, and all six of its touches carried status: "to_be_reviewed". Apollo's schema says approved means ready to send; to_be_reviewed is for workflows that need a human to review first. It reads as a dead campaign in any report. Check touch status before diagnosing copy, lists, or deliverability.

Approving touches starts real email, so the audit reports it and stops. The operator decides.

Grading and output

Give each area its grade and one line of evidence. Then:

1. Fix first: anything that is sending unsafely, or sending nothing while looking live.
2. Watch: things that are fine today and will not be tomorrow (a limit above the ceiling, a guard that never evaluates at this volume, credits that will not cover the next list).
3. Tidy: test sequences, empty lists, stale Context Center.

End with the three actions that matter most, in order, and what each needs from the operator.

Stop at findings. No approvals, archives, deletions, limit changes, or list edits from this skill, however obvious the fix looks.

What the audit cannot see

Say these out loud in the report, so a clean audit is not read as a clean bill of health:

• Mailboxes and domains in another sending platform. The domain check only covers mailboxes connected to Apollo.
• Blacklists and inbox placement. Neither is exposed.
• Reply text. Counts and classes only.
• Anything behind the unpublished tools (domain diagnosis among them) without a master API key on the v1 MCP. See apollo-operator.
• Team-level settings changed in the UI, such as Bounce Guard defaults, beyond what each sequence reports.

Privacy

An audit of someone else's account is full of their data: prospects, list names, campaign names, results. Keep the output with that account, never in anything shared or published, and describe findings by pattern when talking about them elsewhere.

Common mistakes

• Reading an active, silent sequence as a performance result. Check touch status first.
• Trusting a domain verdict without its date. It is the last stored check, not a live one.
• Calling low volume safe. A mailbox limit far above the ceiling is a Fix before it is ever used.
• Listing campaigns from search. Archived sequences still carry history in analytics.
• Fixing things mid-audit. The operator decides, after seeing the whole picture.