1. Boundary
Source webhook to Clay result return and next safe state
The async handoff boundary begins at webhook_in, continues through the send toward Clay and waiting_for_result, and ends only when the result is delivered downstream or moved into a visible exception state such as timed_out or manual_review.
2. Question
Did the async result return and reach the next safe state?
The useful architecture question is not whether the first POST worked. It is whether the async result returned, whether the destination accepted it, and whether timeout or replay states stay visible when the result does not come back cleanly.
3. Risk
An API-like pattern still fails like an async cross-system handoff
Treating Clay like a synchronous API
The first request can succeed while the useful result still has not returned, which leaves a silent gap if the run is marked done too early.
Callback returned but next state is unknown
A callback alone does not prove the destination accepted the result or that replay is still safe.
timed_out exists nowhere
Without a real timeout state, the handoff can stay open indefinitely while operators assume the async job is still healthy.
Retry or replay creates duplicates
If state and destination status are unclear, a recovery action can create duplicate alerts, writes, or downstream records.
4. Minimum fields
You need run state and timestamps, not the whole workflow
run_id The identifier for the full async handoff after webhook in.
source_event_id The upstream event identity that should still match when the callback returns.
received_at When the original webhook or source event entered the system.
sent_to_clay_at When the record was forwarded toward Clay.
callback_received_at When the async result returned from Clay.
current_state The visible state such as waiting_for_result, timed_out, delivered_downstream, or manual_review.
destination_status Whether the next system accepted the returned enrichment result.
retry_count How many controlled retries or replays have been attempted.
5. Suggested check
Design the API-like pattern as a small state machine
Treat Clay as the enrichment engine in the middle of an async job. The receiver needs a short state machine that makes waiting, timeout, destination failure, and replay safety visible without pulling in the rest of your GTM logic.
webhook_in -> sent_toward_clay -> waiting_for_result -> callback_returned -> delivered_downstream / timed_out -> manual_reviewmanual_review -> replay_requested -> replayed_safely -> callback_returned -> delivered_downstream- Accept the source webhook and assign run_id before sending anything toward Clay.
- Move the run to waiting_for_result immediately after sent_to_clay_at is recorded.
- Move the run to callback_returned only when the async result matches the original run.
- Track delivered_downstream separately from callback_returned so acceptance is visible.
- Move the run to timed_out when the result does not return in the chosen window.
- Move unresolved or late states into manual_review before replaying the handoff.
6. No GTM logic required
The API-like pattern is still a narrow handoff boundary
You do not need to reveal the full workflow around Clay to verify whether this async enrichment handoff returned and closed safely. The state model stands on its own.
- No lead scoring logic is needed to know whether the async result returned.
- No routing rules are needed to know whether the run is still waiting_for_result or timed_out.
- No sales assignment model is needed to know whether delivered_downstream actually happened.
- No full GTM workflow required. Clay Relay only checks the async handoff boundary.
7. Synthetic example
Synthetic request, normal run, and timeout branch
These values are synthetic on purpose. The example is only meant to show how an API-like Clay handoff becomes a visible async run instead of a black box.
{
"source_event_id": "evt_synthetic_501",
"email": "maya@example-api.test",
"domain": "example-api.test",
"company": "Example API Co",
"run_id": "cr_run_20260629_501"
}{
"run_id": "cr_run_20260629_501",
"received_at": "2026-06-29T12:00:00Z",
"sent_to_clay_at": "2026-06-29T12:00:04Z",
"callback_received_at": "2026-06-29T12:02:11Z",
"current_state": "delivered_downstream",
"destination_status": "accepted",
"retry_count": 0
}{
"run_id": "cr_run_20260629_502",
"received_at": "2026-06-29T12:04:00Z",
"sent_to_clay_at": "2026-06-29T12:04:03Z",
"callback_received_at": null,
"current_state": "manual_review",
"timeout_at": "2026-06-29T12:06:30Z",
"destination_status": "not_attempted",
"retry_count": 0
}9. What Clay Relay would track
The reliability layer is the run-state layer around Clay
webhook_in
The source event was received and tied to one run_id.
sent_toward_clay
The record actually left the receiver and started the Clay handoff.
waiting_for_result
The run is still open because Clay is working asynchronously.
callback_returned
The result came back and matched the original run.
timed_out
The expected result did not return before the timeout window closed.
delivered_downstream
The next system accepted the returned result cleanly.
manual_review
The run still needs an operator before replay or final delivery is safe.
retry / replay safety
A retry should recover the handoff, not duplicate it.
10. CTA
Check the async handoff boundary before “API-like” becomes silent failure
We can review one Clay enrichment API boundary, show whether waiting, timeout, callback return, downstream delivery, and replay safety are visible, and keep the review scoped to that handoff only.