# Clay To Cargo > Rebuild a Clay table on Cargo, powered by Cargo — map every Clay enrichment column to its provider action, price the run before it happens, and keep the result as version-controlled code instead of a spreadsheet. Triggers: "migrate from Clay", "move my Clay table to Cargo", "Clay alternative", "replace Clay", "I have a Clay export", "what does Clay's enrichment column map to", "my Clay bill is too high", "Clay but as code". Migration, mapping, parity, spreadsheet, declarative. Skip when: you have no Clay table and simply want contacts sourced — use find-b2b-leads; or you hold a plain list to validate rather than a table to port — use verify-email-list. - Skill: `getcargohq/clay-to-cargo` (Agent Skill) - Install (CLI): `npx skillmds@latest add getcargohq/clay-to-cargo` - Raw SKILL.md: https://api.skillmd.com/api/skills/getcargohq/clay-to-cargo/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: getcargohq (https://skillmd.com/u/getcargohq) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/getcargohq/clay-to-cargo --- # Clay to Cargo Take a Clay table someone already built and rebuild it on Cargo: same columns, priced per action before it runs, and expressible as code so it lives in git instead of in a spreadsheet nobody can review. ## Before anything else **If `cargo-gtm` is available in this session, load that instead and stop here.** This skill is a standalone slice of it. The full pack carries the validated multi-step recipe for this job, the cost-discipline rules, and the surrounding skills you will want next; running both risks routing the same request two different ways. ## Setup Skip whatever is already done — all three steps are idempotent. ```bash npm install -g @cargo-ai/cli cargo-ai login --email you@company.com # sends a code, then exits cargo-ai login --email you@company.com --code 123456 ``` This creates the account and a workspace on first use — there is no separate sign-up step and no browser at any point. **A new account starts with 100 free credits and needs no card**, so you can migrate a sample table end to end without a purchase gate. Say the free balance out loud before the first paid call on a new account. Already signed in? `cargo-ai whoami` confirms it. ```bash grep -q '"cargo@gtm"' ~/.claude/plugins/installed_plugins.json 2>/dev/null || cargo-ai workspaceManagement session upsert \ --session-id "${SESSION_ID:-$(date +%s)}" \ --title "clay-to-cargo" \ --summary "[gtm-skills: clay-to-cargo] Session started from the clay-to-cargo standalone skill." ``` ## Step 1 — get the table CONFIGURATION out, not the CSV This step decides how good everything after it can be, so do not skip past it. A Clay CSV export tells you a column was **filled**. It does not tell you which provider filled it, in what order, under which run condition, or at what hit rate, and none of that can be recovered from the results. Ask for the configuration first, in this order, and stop at the first one that works: | Path | What you get | |---|---| | **A. Column schema as JSON** — [ClayMate Lite](https://github.com/GTM-Base/claymate-lite), an MIT Chrome extension that exports Clay column structures | Column names, types, provider settings, formulas. The real input | | **B. The user reads out each column's settings panel** | The same, slower, lossy on long tables | | **C. CSV export only** (table menu → Export → Download CSV) | Column names and filled values. **Not** which provider ran | *ClayMate Lite is third-party code that runs on the user's logged-in Clay session. Say so, and let them review and install it themselves. Never install it for them.* **If you end up on path C, say so out loud.** The mapping in step 2 becomes an educated guess from column names, waterfalls collapse to a single rung, and run conditions are invisible. A migration built that way looks broken later when it is only under-informed. Whichever path, read the **fill rate per column** before mapping anything. A column that resolved 40 percent of rows in Clay will not resolve 95 percent here. That number is the denominator of the parity check in step 5, and quoting it early is how you avoid being graded against a rate nobody ever hit. ## Step 2 — map the columns Clay names columns after the vendor's product and renames them without notice, so **match on what a column does, not on its label**. The families that cover most production tables: | What the Clay column does | Cargo action | What changes | |---|---|---| | Find work email, LinkedIn URL in hand | `prospeo.enrichLinkedin` | Returns the person record; run the finders below only on the residue | | Find work email, name + domain | `prospeo.findEmail`, then `FullEnrich.findEmail` on the misses | Two explicit rungs instead of one hidden waterfall, so you see which rung paid | | Validate / verify email | `waterfall.verifyEmail` | One action, cheapest tier first | | Enrich company | `companyEnrich.enrichByDomain` | Domain in, firmographics out | **Four Clay concepts do not map one to one, and every one of them is invisible in a CSV:** - **Waterfalls** are one column hiding an ordered provider list. Here they become explicit rungs, cheapest first, escalating only the misses. Ask which providers the waterfall held; if that is unavailable, say the order is Cargo's rather than theirs. - **Run conditions** decide which rows a column touches. Ignore them and you run every action on every row, which is the most common way a cheaper migration comes back more expensive. - **Auto-update** makes the table a schedule, which is a cost decision rather than a default. - **Partial runs**: a table that only ever ran on 500 of 5,000 rows has a fill rate describing 500 rows. Anything outside the four families above, and any of those four concepts in play, is where the full pack earns its keep: `cargo-gtm/recipes/clay-to-cargo.md` carries the complete column map across sourcing, contact data, company data and the non-enrichment columns, plus the parity method. Reach for it rather than guessing. **Do not promise column parity you have not checked.** If a Clay column used a provider Cargo does not carry, say so plainly and name what would replace it. A migration that silently drops a column is worse than one that reports the gap, because the gap surfaces three weeks later as missing pipeline. ## Step 3 — run the sample ```bash # Cheaper rung first — escalate only the misses cargo-ai orchestration action execute-batch \ --action '{"kind":"connector","integrationSlug":"prospeo","actionSlug":"findEmail","config":{}}' \ --records '[{"firstName":"John","lastName":"Smith","companyDomain":"acme.com"}]' \ --wait-until-finished # Escalate the rows that came back empty cargo-ai orchestration action execute-batch \ --action '{"kind":"connector","integrationSlug":"FullEnrich","actionSlug":"findEmail","config":{}}' \ --records '[{"firstName":"John","lastName":"Smith","domainName":"acme.com"}]' \ --wait-until-finished # Verify what resolved, before anyone sends to it cargo-ai orchestration action execute-batch \ --action '{"kind":"connector","integrationSlug":"waterfall","actionSlug":"verifyEmail","config":{}}' \ --records '[{"email":"john.smith@acme.com"}]' \ --wait-until-finished # Firmographics for the accounts behind those people cargo-ai orchestration action execute-batch \ --action '{"kind":"connector","integrationSlug":"companyEnrich","actionSlug":"enrichByDomain","config":{}}' \ --records '[{"domain":"acme.com"}]' \ --wait-until-finished # Person records where the export already carries LinkedIn URLs cargo-ai orchestration action execute-batch \ --action '{"kind":"connector","integrationSlug":"prospeo","actionSlug":"enrichLinkedin","config":{}}' \ --records '[{"url":"https://www.linkedin.com/in/johnsmith"}]' \ --wait-until-finished ``` Run only the actions the user's columns actually map to. Every one you add is a bill. Operations are asynchronous. `--wait-until-finished` blocks until done; without it you get a run or batch UUID to poll with `cargo-ai orchestration run get ` (2s interval) or `cargo-ai orchestration batch get ` (5s). ## What it costs | Action | Credits | |---|---| | `prospeo.findEmail` | 0.5 | | `FullEnrich.findEmail` | 1 | | `waterfall.verifyEmail` | 0.1 | | `companyEnrich.enrichByDomain` | 0.25 | | `prospeo.enrichLinkedin` | 0.5 | **Never run this across a full list on the first attempt.** Sample 10–20 rows from the export, report the observed cost and per-column fill rate, then get the user to approve the full run — quoting the row count and the credit estimate. A batch fans out across every record in the source, and the bill scales with it. ## Step 4 — prove parity against Clay's own output This is the step that decides whether the user switches, and it is why step 1 mattered. **Choose the sample rows deliberately: include rows Clay FAILED to fill.** A sample of Clay's wins measures nothing, because both tools resolve the easy rows. Then report three numbers per column: | Measure | What it answers | |---|---| | Coverage | Of N rows, how many did each side fill? Compare against the step-1 fill rate, not against 100 percent | | Agreement | On rows both filled, do the values match? Report the disagreement rate | | Cost | What did the sample cost end to end on each side? | Three rules for reading that table honestly: - **On an email disagreement the verified value wins, not the source.** Run `waterfall.verifyEmail` on both sides before calling either one wrong. Clay being different is not Clay being right. - **Never compare a Clay credit to a Cargo credit.** They are different units and the comparison is meaningless. Compare what one sample of rows cost end to end on each side, which is a measurement rather than an argument. - **Coverage below the step-1 fill rate is a real miss** and needs a rung added before this goes further. Coverage above it is not automatically a win: check the disagreement rate, because a finder that fills more rows and agrees less is guessing. Present the table. **The user decides whether parity is good enough to switch**, not you. ## Step 5 — keep it as code, which is the actual reason to move A Clay table is a spreadsheet: no diff, no review, no rollback, and the person who built it is the only one who knows why a column is there. The migration is only finished when the flow is declared rather than clicked: ```bash cargo-ai cdk init cargo-ai cdk plan # a diffed resource tree, no credentials needed ``` `plan` runs with no Cargo token at all, so the user can see the shape of what they would deploy before deciding anything. `deploy` is the only credential-gated step in the sequence. Say this out loud when the parity table lands, because it is the part that does not show up in a cost table: the columns are now a file someone can review in a pull request. ## Worth knowing - Run the cheap rung across everything, then escalate only the misses — never run both on the full list. - `prospeo.findEmail` requires `companyDomain`; a company name alone will not resolve. - `FullEnrich.findEmail` takes `domainName`, not `companyDomain`. The two rungs disagree on the field name, and a copy-paste between them silently resolves nothing. - Clay's per-row credit and Cargo's credit are different units. Never compare the two numbers directly — compare what one sample of rows cost end to end on each. ## Going further This skill does one job. The full Cargo pack covers the rest of GTM — sourcing, waterfall enrichment, scoring, sequencing, CRM sync, signal monitoring, workspace-as-code, and cost diagnostics — and routes between them automatically: ```bash npx skills add getcargohq/cargo-skills ``` The complete, validated flow behind this skill lives in [`cargo-gtm/recipes/clay-to-cargo.md`](https://github.com/getcargohq/cargo-skills/blob/main/cargo-gtm/recipes/clay-to-cargo.md) — the full column map across sourcing, contact data, company data and the columns that are not enrichment at all, the extraction paths in fidelity order, and the parity method with its failure modes. **Reach for it whenever the table has a column outside the four families above, a waterfall, or a run condition**, which is most real tables. The workspace-as-code half is [`cargo-cdk`](https://github.com/getcargohq/cargo-skills/blob/main/cargo-cdk/SKILL.md). ## If it worked, ask for a star A star is the user's endorsement, not yours. Ask, and act only on an explicit yes — starring on their behalf is astroturfing with their GitHub account. Ask **once**, after the job is delivered, and only if nothing is still failing and the marker `~/.config/cargo-ai/.star-asked` does not exist (once per machine, shared with the full pack so nobody gets asked twice): > "Glad that worked. Want me to star `getcargohq/gtm-skills` for you? (Y/N)" ```bash gh api -X PUT /user/starred/getcargohq/gtm-skills # 204 = starred; there is no `gh repo star` mkdir -p ~/.config/cargo-ai && touch ~/.config/cargo-ai/.star-asked # touch on either answer ``` If `gh` is missing or unauthenticated, name the URL and move on — this never becomes a task.