Skip to content

v1.3.0 — Call intelligence, credit control, and verify-first lists

Choose a tag to compare

@jimmy-resetar jimmy-resetar released this 31 Aug 13:15
· 9 commits to main since this release

Three new capabilities, all of which make a campaign cheaper to build and more likely to land.

Call intelligence feeds the brief

If your team records calls in Apollo, the best research material for your positioning is already in your account, and reading it is free.

conversations show returns a structured call_summary: objections, pain points, outcome, next steps, and pricing discussion. Five direct inputs to the brief, in your buyers' own words rather than marketing's.

A website is how a business describes itself. A recorded call is how its buyers describe their problem. When the two disagree, the call wins, and business-brief now says so.

Credit control

Credits are eleven separate pools, not one balance, and the ratio changes how you plan: the AI pool is 200× the contact-data pool. Apollo prices generation as near-free and data as scarce. So the expensive part of a campaign is finding and verifying people, not writing to them.

Three measured rules that cut real spend:

  • The free has_email filter. Search returns it on every row, before you spend anything. Records without it come back empty or with a guessed address, and both still cost a credit. Filtering first took an enrichment yield to 99.7% verified.
  • You pay per record attempted, not per email found. Misses cost the same as hits.
  • Re-enrichment recharges. There is no "already paid for this one" discount, which is why suppression earns its place.

Plus the hard cap nobody documents: 10 records per enrichment call, and the CLI does not batch for you.

Verify-first lists

The pipeline is reordered: search → filter → dedupe → suppress → enrich → verify → write copy.

Verification moved ahead of copy because personalising an address that will never receive anything is pure waste. The evidence: 997 addresses graded verified by the provider were 564 safe to send, 413 catch-all, and 3 that would have bounced. Three bounces in a small first batch is a live deliverability incident on a young domain, and no amount of good copy prevents it.

Also new

  • First-party intent as a fourth kind of angle, plus a table mapping every advanced filter to the kind of angle it builds.
  • Bounce Guard documented, including the trap: it does not evaluate below 200 emails, so small sends and the first days of a ramp are unprotected.
  • Follow-up craft: how the greeting tightens across a thread, and the four things to cut from every follow-up.
  • Sequence build mechanics: the exact payload shape, step ids on update, and the schedule fields that decide when anything actually sends.
  • A list gets into Apollo as a real list, in checkpointed batches, with the list attached properly.

Kept current

Five things moved under us since v1.2 and are now corrected with dates, so you can tell what changed and when:

  • The flagship MCP-only filter example moves to NAICS, since --department-headcount landed in CLI v2.1.0. Eight of nine remain CLI-less and a new MCP-only family appeared, so the four-lane model got stronger.
  • Per-contact personalisation no longer needs REST. apollo fields create exists now.
  • conversations is a full CLI command group, not REST-only.
  • Step 2 is the lightest email, not step 3.
  • Pagination overlap is no longer guaranteed: zero duplicates across 43 pages, against 9% in July.

Read these before your next launch

  • Bulk contact creation does not deduplicate, despite documenting that it does. Never retry on a timeout.
  • Enrollment can fail silently, returning exit 0 with an empty campaign. Assert on the response body.
  • Sequences cannot be read back. A human in the UI is the only verifier, so every skill that creates one now hands you the link.
  • The MCP session can expire mid-task while the CLI token keeps working.

Still 17 skills. Built by Creatop, and everything above was found by running it, not by reading the docs.