Building Clay Relay: Enhancing Reliability for Clay Inbound Enrichment Workflows

Hey everyone, I’m building a small project called Clay Relay. I’m looking at one narrow problem: reliability around Clay inbound enrichment workflows. A lot of Clay workflows look simple on paper: lead source sends webhook Clay receives the row Clay enriches asynchronously HTTP API sends the result out Slack, CRM, webhook, or another system should receive it The failure point is often not Clay alone. It is the gap between systems. Some cases I’m studying: * callback URL is stale or misconfigured * callback body is missing the run ID * enrichment finishes, but the result does not reach the next system * timeout happens silently * retry means manually resubmitting and hoping nothing duplicates Clay Relay is my attempt to test a narrow reliability layer around this flow: webhook in forward to Clay callback receiver run status timeout alert webhook out manual retry / replay Not a Clay competitor. Not a workflow builder. Just a small reliability layer around inbound Clay handoffs. I’m here to learn from people building real Clay workflows, especially RevOps teams, agencies, and GTM engineers using Clay for inbound leads or enrichment pipelines. Curious where your Clay workflows usually break: callback, timeout, result handoff, retry, or something else?