Apollo + SalesCrew
Apollo is a data-source provider for the SalesCrew data bank. Contacts and companies import and enrich into your own Postgres project, where they stay after you cancel anything.
- Import and enrich
- Rows land in your database
- Verify before you send
The short answer
- The mechanism is a data-source provider: SalesCrew pulls contacts and companies from Apollo into the data bank in your instance. The rows are yours, in your Postgres project, and a full database dump takes them with you.
- Enrichment fills gaps rather than overwriting what you already know. A record that already has a title keeps its title; a blank field gets filled.
- Verify before you send. A contact's status in any provider's export is a claim about the past, and treating it as proof of a live mailbox is how bounce rates climb.
Mechanism
One provider, two operations, and the parts that stay yours.
| What | Mechanism | Direction | Objects | Status |
|---|---|---|---|---|
| Contact and company import | Data-source provider into the data bank | Inbound | Contacts, companies | Available |
| Enrichment | Fill-gaps-never-clobber against existing records | Inbound | Contacts, companies | Available |
| Where rows live | Your instance's own Postgres project | : | Data bank tables | Available |
| Publishing to a segment | data_bank_publish into contacts, then segments and ICPs | Internal | Segments, ICPs | Available |
| Suppression on publish | Enforced at audience freeze and again at send | Internal | Suppression entries | Available |
| Writing back to Apollo | Not built | , | , | Not available |
| Sequences inside Apollo | Not used. Cadences run in SalesCrew | , | , | Not planned |
Mechanisms read from the SalesCrew integration table, September 2026. Apollo's own site is the authority on its plans, credit model and data coverage.
Setup
The important step is the last one, and most teams skip it.
- 1
Add the Apollo key
Settings, integrations. The key goes into your instance's vault. integration_set_key does the same from an agent or a script.
- 2
Define the ICP
Titles, company size, industry and geography as an ICP record, so the same definition drives both sourcing and reporting. icp_create is the MCP twin.
- 3
Pull into the data bank
Rows land in the data bank rather than straight into your contact list, so a bad pull is a table you can throw away rather than a mess in the CRM.
- 4
Query and cut
data_bank_query filters the pull before anything is published. Look at geography and title coverage here; that is where imports usually disappoint.
- 5
Publish a segment
data_bank_publish promotes the rows you kept into contacts, and the segment freezes with suppression applied.
- 6
Verify the addresses
Run a verification pass before the first send. Treat any provider's email status as a hint, not as a guarantee.
Questions
- Do I still need an Apollo subscription?
- Yes. Apollo is the data source and you pay Apollo for the data. SalesCrew is where the rows land, get filtered, get published and get worked.
- Can I import a CSV instead?
- Yes. The data bank takes CSV as well as provider pulls, and a scraper or any other source can publish through the same ingest contract. Nothing forces you through one vendor.
- Does enrichment overwrite my data?
- No. It fills gaps and leaves existing values alone. That rule matters when the CRM already holds hand-corrected records that a bulk enrich would otherwise flatten.
- Is the data mine after I leave?
- Your instance is its own Postgres project. Export is a full database dump plus CSV everywhere, and the rows you paid Apollo for come with it. Apollo's own terms govern what you may do with their data after that.
- Will SalesCrew scrape for me?
- No. SalesCrew ingests from providers and files you supply. Where you get contacts, and on what legal basis you contact them, is your decision and your obligation.
Pull one ICP into the data bank and look at it honestly
Query the coverage before you publish a single contact into the pipeline.