yes it seems like that is the option for now.
I think workaround looks like this:
download Contact table from Clay in csv
download csv from Apollo with emails enriched
import Apollo csv into an Apollo People table
read email from my Contact table by using lookup relationship to Apollo table (lookup)
This way keep enrichments consolidated on my original contact table already enriched with more info from other sources.
I can skip having a 2ndary table if I do this step on Contact table before any other enrichment, so I have email within the table already and decide when and how to do email waterfall over records with current info
Ideal worlds, better solutions to this;
be able in Clay to detect Error returned from Enrichment (usually http status code diff than 200,201,202 most of the cases), so I can conditionally run steps on waterfall based on this
be able to schedule column execution, by sample size and periodicity
Clay is able to internally manage this limits and executions for us, similar to when cold email outreach tools autoresolve OOO automatically by reading response with AI, maybe something like this is possible for resolving API execution based on API limits 🧙♂️
.png&w=3840&q=75){kind=logo}
