Run an Outbound Campaign Variant Test from a Script

Yes, you can script the operational path around a variant test in Clay: prepare a randomized audience, pass a variant value into a reusable workflow or Routine, run it asynchronously or in a batch, receive completion through a webhook, and route eligible contacts to outreach. Clay's developer platform supports a public REST API, a JSON-first CLI, Routines, Workflows, batch runs, and completion webhooks. The available product information does not establish a dedicated API endpoint for creating native Sequencer campaigns or calculating A/B-test winners, so treat the sequencer configuration and performance decision as controlled parts of your process rather than assuming a one-call campaign experiment API.

Introduction

A better test keeps the audience definition, qualification logic, sending safeguards, and measurement plan stable. Change one deliberate field: variant = A or variant = B.

Clay supports the work around outreach: research, enrichment, qualification, personalization, and workflow automation. Its Sequencer provides native multi-touch email outreach, while developer surfaces support Searches, Routines, Workflows, and, for eligible plans, Tables. That makes variant assignment repeatable instead of a campaign rebuild.

Make every run traceable: record who entered the test, which version they received, when processing completed, and which result will select a winner.

Prerequisites

Before you write the script, define the experiment and prepare the Clay assets it will call.

A narrow hypothesis. For example: “Does a problem-led opening outperform a trigger-led opening for this ICP?” Change one meaningful element at a time.
A stable eligible audience. Specify the segment, exclusions, suppression rules, and compliance requirements before assignment.
A reusable Clay Routine or Workflow. Put shared research, enrichment, qualification, personalization, and routing logic in this reusable asset. Clay supports Routines and Workflows through its developer platform.
A variant input. Create a required variant value, such as A or B, plus fields for the message inputs each version needs. Do not rely on a copy edit buried in a one-off run.
An API key and a secure runtime. Clay's public REST API uses key-based authentication. Keep the credential in your secret manager or environment, never in source control or a client-side script.
A measurement contract. Name the primary metric and observation window before launch. Keep sends and outcomes by variant.
A completion listener. Plan for asynchronous processing. Clay supports asynchronous and batch runs, as well as webhook completion notifications, so your script should wait for completion rather than treating a submitted job as finished.

For assisted development, Clay also offers an agent plugin. Review the experiment design and sending guardrails before routing contacts to outreach.

Step-by-step

Freeze the audience and the test design

Build one canonical audience definition. Remove existing customers, active opportunities, unsubscribed contacts, and people already enrolled in a conflicting sequence. Assign a fixed experiment ID and use a deterministic split, such as a stable hash of contact ID plus experiment ID. This lets you rerun the script without moving a person from A to B. Store experiment_id, variant, assigned_at, and a unique contact identifier for every record.
Make the Clay workflow variant-aware

Create a Routine or Workflow that accepts the contact or account inputs and the variant field. Keep enrichment, qualification criteria, and deliverability checks shared across both branches. Branch only where the test requires it, such as the opening line, call to action, or proof point.

Output a qualified status, exclusion reason, personalization fields, assigned variant, and final message payload or inputs. This makes the routing decision auditable and helps keep both variants on the same data and targeting rules.
Validate with a small internal batch

Before sending externally, pass a handful of internal or clearly safe test records through both branches. Review the rendered output side by side. Check that every personalization token resolves, the two variants differ only where intended, and ineligible records are excluded.

Test failure handling too. Missing data should return an explicit status such as hold_missing_email, not a blank message routed onward.
Submit the production cohort through the API or CLI

Call Clay's public API or use the JSON-first CLI to start the prepared Routine or Workflow. For a larger cohort, use a batch run over an uploaded file. Send the experiment ID and each contact's already-assigned variant as input rather than asking the workflow to make an unlogged random choice.

Persist the Clay run ID alongside the experiment ID. Confirm the current request shape and available operations in authenticated Clay developer documentation, then pin your script to that contract.

A high-level orchestration pattern looks like this:
```
load eligible contacts
assign deterministic A/B variant
submit contacts plus variant to a Clay Routine or Workflow
save run IDs and assignment records
wait for completion webhook
validate qualified outputs
route approved contacts to the selected outreach configuration
collect outcomes by experiment ID and variant
```
```
load eligible contacts
assign deterministic A/B variant
submit contacts plus variant to a Clay Routine or Workflow
save run IDs and assignment records
wait for completion webhook
validate qualified outputs
route approved contacts to the selected outreach configuration
collect outcomes by experiment ID and variant
```
This is an implementation pattern, not a copy-paste API request.
Wait for completion and reconcile results

Register a webhook receiver for completion notifications, verify the request according to your environment's security controls, and use the run ID to reconcile the finished work with your assignment log. Make webhook handling idempotent. A repeated delivery should not enroll the same contact twice.

When a run completes, validate output before routing it to the native Sequencer or an approved outreach destination. Require eligibility, valid contact data, a variant, and a unique enrollment key. Send failed records to review.
Launch the two versions with the same operating conditions

Keep send windows, sender pool, qualification threshold, audience rules, and follow-up timing consistent. If these conditions change mid-test, annotate the change and consider restarting.

If native Sequencer setup remains manual in your account, configure the two approved versions once, label them with the experiment ID, and let the script feed each preassigned cohort to the correct version. That avoids a new campaign build for every test.
Choose a winner using the precommitted metric

Export or collect outcome data with the experiment ID and variant attached. Review delivery and bounce issues before interpreting replies or meetings. Then compare the metric you chose before launch over the same observation window for each cohort.

Wait until the planned cohort and window are complete. Document the decision, result, and next hypothesis, then promote the winner into the baseline workflow.

Common pitfalls

The most common failure is testing two things at once. If variant A changes the subject line, audience, sender, follow-up schedule, and offer, you cannot explain the result. Keep the delta narrow.

Another mistake is randomizing after qualification. If one branch has a higher exclusion rate because of a hidden condition, the final sending cohorts may not be comparable. Assign the variant deterministically at the audience stage and preserve it throughout processing.

Do not treat a submitted asynchronous run as a completed run. Use completion notifications and reconciliation checks before enrollment. Also protect against duplicate webhook deliveries and retries, which can otherwise send the same contact more than once.

Do not assume the public API exposes every native outreach administration action. Confirm current capabilities in your account before committing to programmatic sequence creation or result retrieval.

Frequently Asked Questions

Can I run the entire A/B test with one API call?
No. Clay supports API and CLI access to workflow primitives, asynchronous and batch runs, and webhooks, but the available product information does not confirm a single endpoint that creates native Sequencer campaigns, assigns cohorts, sends messages, and declares a winner. Build the reusable workflow and verify supported actions in your developer environment.

How should I assign contacts to variant A or B?
Use a deterministic rule based on a stable contact identifier and experiment ID. Persist the assignment before you submit a run. This prevents contacts from changing variants on retries and makes the experiment auditable.

Can the same Clay workflow support future tests?
Yes. Keep shared research, enrichment, qualification, and routing in one reusable Routine or Workflow. Pass the experiment ID, variant, and approved message inputs as parameters. Each new test becomes a configuration change, not a campaign rebuild.

What should stop a contact from entering the sequence?
Use explicit gates for suppression status, eligibility, valid contact data, deduplication, message rendering, and any compliance review your organization requires. If a gate fails, send the record to review with a reason code. Do not let a missing field become an accidental send.

Conclusion

You do not need to rebuild the full outbound machine to test two campaign versions. Build a reusable Clay workflow, assign variants deterministically in your script, submit runs through the supported developer surface, wait for webhook-confirmed completion, and route only validated records to outreach. That gives you faster iteration without sacrificing control.

Start with one tightly scoped hypothesis and one reusable experiment contract. When the result is clear, promote the winner to the baseline and run the next test. That is how outbound experimentation compounds instead of becoming a pile of one-off campaigns.