How to Replace Clay With Codex, Part 1: Audit the Workflow

The safest way to replace Clay with Codex is to spend the first day running no enrichment at all. Audit the workflow first. If you cannot explain every step on paper, you cannot tell whether the replacement behaves the same way.

A Clay table is not a workflow specification

A Clay table shows rows, columns, formulas, enrichments, and results. It does not automatically give a future operator one complete answer to these questions:

• What event allows a row to enter the workflow?
• Which original fields must never be overwritten?
• Which columns transform existing data and which buy new data?
• Which provider runs first, and what result is good enough to stop?
• Which AI prompt makes a decision instead of extracting a fact?
• What happens after a timeout, empty result, malformed response, or conflict?
• Which steps require a human approval before money is spent or a destination is changed?
• How do you prove that the CRM or sequencer accepted the intended records?

That missing explanation is the real migration risk. A replacement can return a polished CSV and still be wrong because it skipped a suppression rule, retried a paid provider twice, overwrote source evidence, or uploaded rows that were never approved.

Start with seven contracts

For each current workflow, write seven small contracts. They can live in a spreadsheet at first.

1. Entry contract. The event, file, state, or approval that permits a row to enter.
2. Input contract. Required fields, accepted formats, stable IDs, and immutable source values.
3. Execution contract. Every transformation, provider call, model task, and destination write in order.
4. Decision contract. Success, stop, skip, reject, partial, and review conditions.
5. Spend contract. Which step consumes a Clay Action, a Data Credit, or money through your own provider key.
6. Failure contract. Timeouts, retries, maximum attempts, error queues, and escalation ownership.
7. Delivery contract. The exact payload, destination, idempotency key, and readback that proves acceptance.

Clay's current documentation makes the spend split important. Actions measure platform work, while Data Credits pay for data or AI from Clay's marketplace. A bring-your-own provider key can remove the Data Credit charge while the Clay Action still remains. Your audit should preserve those as separate lines.

Build one audit manifest

Give every step a stable ID. Do not use the column letter as the ID because columns move. Do not store API secrets in the manifest. Store a safe connection name or environment-variable pointer.

step_id,column_name,role,trigger,input_fields,
tool_or_provider,condition,success_contract,
failure_route,cost_meter,output_fields,
destination,approval_owner,evidence

S01,Find company domain,source,on_import,
company_name,Apollo account search,
domain_is_blank,one normalized domain,
manual_review,provider_api,company_domain,
workflow_state,ops,provider_response_url

S02,Find work email,enrichment,after_S01,
first_name+last_name+company_domain,
Prospeo_then_Hunter,email_is_blank,
verified_candidate_or_no_result,
retry_once_then_review,provider_api,
email+provider+checked_at,workflow_state,
ops,request_id

S03,ICP decision,decision,after_S02,
company_domain+role+evidence,
versioned_rule_set,required_evidence_present,
fit_partial_or_reject,review_queue,
model_api,fit_state+reason,workflow_state,
campaign_owner,evidence_urls

The exact providers will differ. The shape should not. One row in this manifest must be enough for another operator to understand what the step needs, what it costs, what counts as success, and where failure goes.

Classify every Clay column by job

Clay documents text, formula, and enrichment behavior at the column level, with separate limits for total columns and enrichment columns. For migration, the more useful classification is operational:

• Source. Imports a person, account, signal, or API dataset.
• Transform. Normalizes, parses, joins, calculates, or formats existing values.
• Enrichment. Requests a new fact from a provider, website, or AI tool.
• Decision. Scores, accepts, rejects, routes, or asks for review.
• Delivery. Writes to a sheet, CRM, ad audience, or sequencer.
• Control. Holds cost, state, retries, timestamps, approvals, and readback evidence.

The control columns are the ones most likely to disappear in a rushed rebuild. They are also the ones that prevent duplicate spend and unapproved delivery.

Separate orchestration cost from data cost

As of July 16, 2026, Clay's pricing page lists Free, Launch, Growth, and Enterprise plans. The live annual display starts Launch at $167 per month and Growth at $446 per month, while Clay's FAQ states monthly starting prices of $185 and $495. Clay also separates Actions from Data Credits.

That does not mean a Codex rebuild is automatically cheaper. Your replacement cost model needs four independent meters:

• Orchestrator cost. The Codex or Claude Code plan, API, or runtime that owns the run.
• Worker-model cost. Input, output, retries, and any web-search or extraction tools used per row.
• Provider cost. Apollo, Prospeo, Hunter, verification, scraping, and other paid APIs.
• Operator cost. Review time, exception handling, maintenance, and incident recovery.

Compare those with your current Clay subscription, Actions, Data Credits, connected-provider bills, and operator time. If you count only the SaaS subscription, the decision will be wrong in both directions.

Map every condition and stop rule

A provider list is not a waterfall until it has stop rules. For each paid or rate-limited step, document:

• The eligibility condition before the call.
• The minimum acceptable result after the call.
• The fields that must be present together.
• The confidence, freshness, or verification threshold.
• The next provider when the result fails.
• The maximum number of calls for one row.
• The reason code written when the workflow stops unresolved.

This is deliberately distinct from the provider waterfall build guide. That article shows how to route enrichment. This audit records the current behavior so the new waterfall can be tested against it.

Preserve evidence before values

Do not migrate only the final email, title, fit score, or personalization line. Preserve the evidence envelope that made the value usable:

• Source URL or provider record ID.
• Retrieved time and provider or rule version.
• Raw response or artifact hash when permitted.
• Selected value and the rule that selected it.
• Confidence or verification state.
• Conflict, retry, and review history.

The lead-list source-of-truth layer explains how to store those observations. The audit only needs to prove which evidence each current step creates and which downstream decisions depend on it.

A real reason to audit before automating

In a recent anonymized outbound operation, a raw export contained more than 100,000 rows. The file existed and its schema was known, but the targeting and campaign-use decision had not been approved. The correct system state was not ready to enrich. It was artifact present, processing permission absent.

Because approval state was kept separate from file state, no enrichment, upload, or launch was treated as authorized. This is not a performance case study and it does not prove a financial return. It demonstrates the narrower control that a workflow audit must preserve: possession of data is not permission to spend money on it or send it downstream.

Create a migration test set before code

Select a small representative sample from the current workflow. Include ordinary rows and deliberate edge cases:

• A complete row that should pass every step.
• A missing-domain row that should route to research.
• A provider conflict that should require review.
• An unresolved email that should stop before delivery.
• A suppressed or already-contacted record that must never enter a campaign.
• A provider timeout and a malformed model response.
• A duplicate rerun that must not create a second destination record.

Save the expected state after every step, not only the final CSV. Part 2 will use those fixtures to test the Codex orchestrator at each checkpoint.

Choose keep, hybrid, or replace

The audit should end with a decision, not an automatic cancellation.

• Keep Clay. Keep it when the visual interface, marketplace, collaboration, signals, or non-technical ownership is worth more than the savings from custom code.
• Use a hybrid. Keep Clay for sourcing or selected enrichments, but move deterministic transforms, evidence storage, approvals, or downstream readback into code you own.
• Replace the workflow. Replace it when the logic is stable, volume is recurring, your team can maintain the system, and the audit proves every contract can be tested outside Clay.

Clay and Apollo are also not direct substitutes. Apollo is primarily a data and sales-engagement platform. Clay is an orchestration and enrichment layer. A Codex system can coordinate Apollo and other providers, but it does not make those underlying data sources disappear.

Use Codex to produce the audit, not to guess it

Codex can inspect exported configuration notes, screenshots, formulas, prompts, provider documentation, and sample rows. Give it a read-only evidence folder and require an exception list for anything it cannot prove.

clay-audit/
  evidence/
    screenshots/
    prompts/
    provider-docs/
    sample-rows/
  workflow.csv
  decisions.md
  costs.csv
  failures.csv
  approvals.md
  migration-tests/
  unresolved.md

A useful audit prompt is: Inventory the observed workflow. Do not run live providers or modify destinations. For every step, cite the evidence file, mark unknowns explicitly, separate observation from inference, and write the result to the audit manifest.

OpenAI's current Codex documentation describes the CLI as a way to inspect, edit, run commands, and automate repeatable work. The important word here is inspect. The first Codex job in a migration should recover the existing contract, not improvise a new one.

Definition of done for Part 1

Do not start the orchestrator until the audit can produce all seven artifacts:

1. A step-by-step workflow manifest with stable IDs.
2. A field schema with immutable inputs and accepted outputs.
3. A decision table with conditions, stops, fallbacks, and review rules.
4. A cost model that separates orchestration, data, models, and operator time.
5. A failure matrix with retries, quarantine, and ownership.
6. An approval matrix from processing permission through campaign launch.
7. A representative migration test set with expected intermediate states and destination readback.

If one of those is missing, the correct status is audit incomplete, not ready to build.

Continue to Part 2

Part 2 turns this manifest into a resumable Codex orchestrator with batch IDs, bounded workers, checkpoints, idempotency keys, retry budgets, and a controlled crash-recovery test. The audit becomes executable acceptance criteria instead of a document that sits beside the code.

Frequently asked questions

What does Clay software do?

Clay sources or imports records, transforms data, calls enrichment and AI providers, applies row-level logic, and pushes results to downstream systems. Its HTTP API can pull data in as a source or enrich existing rows one record at a time.

What should replace Clay?

There is no universal replacement. A Codex or Claude Code workflow is a strong option when you want to own the orchestration, rules, evidence, and integrations. You still need data providers, a storage layer, and a sequencer or CRM.

Is there a free version of Clay?

Yes. As of July 16, 2026, Clay lists a Free plan with 500 Actions per month, 100 Data Credits per month, unlimited seats and tables, multi-provider waterfalls, Claygent, and a 200-row limit per table. Check the live pricing page because plan details can change.

Is Clay better than Apollo?

They solve overlapping but different problems. Apollo is primarily a B2B database and engagement platform. Clay is primarily an orchestration and enrichment workspace that can use many providers. The right architecture may use both.

How much is a Clay subscription?

Clay's annual display currently starts Launch at $167 per month and Growth at $446 per month. Its pricing FAQ also shows monthly starting prices of $185 and $495. Enterprise is custom, and Actions or Data Credits can affect the total cost.

Should I cancel Clay before the audit?

No. Keep the current workflow available while you document it and build test fixtures. Cancel only after the replacement passes the agreed behavior, cost, failure, approval, and readback tests.

Can this audit be done without exposing API keys?

Yes. Record connection names, provider accounts, secret locations, and required scopes. Never copy credentials into the audit manifest, prompts, screenshots, or article.