Clay + SalesCrew
No connector, and none needed for the common case. Clay builds and enriches the list, then an HTTP column or a CSV puts the finished rows into your own data bank.
- HTTP column or CSV
- No Clay connector
- Rows land in your database
The short answer
- SalesCrew has no Clay integration in either direction. The practical route is Clay's own HTTP API column posting into your instance, or a CSV export into the data bank.
- That division of labour is honest about what each tool is for. Clay is a research and enrichment workbench. SalesCrew is where the finished list becomes a segment, a cadence and a pipeline you can report on.
- Rows arriving from Clay land in the data bank rather than straight into contacts, so a run that went wrong is a table you delete rather than a mess inside the CRM.
Mechanism
Two working paths, and one direction that does not exist.
| What | Mechanism | Direction | Objects | Status |
|---|---|---|---|---|
| Clay connector in either catalogue | Does not exist | None | None | Not available |
| Clay to SalesCrew, row by row | Clay HTTP API column posting to your instance | Inbound | Data bank rows, contacts, companies | Available |
| Clay to SalesCrew, in bulk | CSV export into the data bank | Inbound | Data bank rows | Available |
| Publishing into the CRM | data_bank_publish after you have filtered the pull | Internal | Contacts, companies, segments | Available |
| Suppression | Applied when the audience is frozen and again at send | Internal | Suppression entries | Available |
| SalesCrew to Clay | Not built. Nothing is written back | None | None | Not available |
Mechanisms read from the SalesCrew integration table, September 2026. Clay's own site is the authority on its credit model and its HTTP column behaviour.
Setup
One HTTP column, and a discipline about where rows land.
- 1
Build the table in Clay
Sourcing, waterfalls, enrichment and whatever scoring you do there. That work stays in Clay; SalesCrew is not trying to replace it.
- 2
Issue a scoped token
mcp_token_issue with the narrowest scope that can write into the data bank. You can revoke it the moment the run finishes.
- 3
Add an HTTP column
Post each finished row to your instance. Send a stable external identifier so a rerun updates rather than duplicates.
- 4
Land in the data bank, not in contacts
That is the whole point. A bad enrichment run should be a table you throw away.
- 5
Query before you publish
data_bank_query filters the rows. Check email coverage and geography here, because that is where imports usually disappoint.
- 6
Publish and freeze
data_bank_publish promotes what survived, then the segment freezes with suppression applied before a cadence touches it.
Verify before you send
Questions
- Do I still need Clay?
- If you use Clay for waterfall enrichment and custom research, yes. SalesCrew's data bank imports and enriches through a provider such as Apollo; it is not a research workbench.
- Can SalesCrew push rows back to Clay?
- No. The path is one way, into your instance.
- How do I avoid duplicate contacts?
- Send a stable external identifier from Clay so reruns update the same row. Duplicate detection and merge inside the CRM is a roadmap item, so getting the identifier right now saves cleanup later.
- Is the data mine?
- The rows sit in your own Postgres project and leave with a full database dump. What you may do with data you bought is governed by the provider's terms, not by us.
- Which tier includes the data bank?
- Core at $299 a month, with unlimited seats. Data sources and the marketing module sit on Agency at $1,200.
Let Clay build the list and SalesCrew work it
One HTTP column into your own data bank, filtered before anything is published.