1. Boundary
Returned Clay callback to matched run and next safe state
This boundary starts when a Clay callback returns and ends only when that callback is matched to the original run, checked for duplicate or late delivery, and either confirmed as safe for the next state or moved into manual_review.
2. Question
Does the callback match the original run and belong in the next state?
A Clay callback handoff is only healthy when run_id and source_event_id match the original send, duplicate callback risk is cleared, and destination_status still confirms the next step can happen safely.
3. Risk
Matching, duplicate, and late-callback failures are the real checklist items
Callback does not match the original run
A Clay callback handoff fails if the returned payload cannot be tied back to the original run_id and source_event_id safely.
Duplicate callback creates duplicate side effects
An exact repeated Clay enrichment callback can create duplicate CRM writes, duplicate alerts, or duplicate outbound sends unless duplicate prevention exists.
Late callback hides a timeout history
If callback_received_at arrives after timeout_at, the run should not be presented as a normal completion. completed_after_timeout needs to stay visible.
Callback received is mistaken for destination accepted
A matching callback is not the same as downstream delivery confirmation. destination_status needs its own boundary check.
4. Minimum fields
The checklist needs correlation fields and state, not the full system
run_id The primary identifier for the original send and the returned Clay callback.
source_event_id The upstream event identity that should still match when the Clay webhook callback returns.
sent_to_clay_at When the original payload was actually handed off toward Clay.
callback_received_at When the Clay enrichment callback reached the receiver.
payload_hash A stable hash for identifying exact duplicate callbacks safely.
destination_status Whether the next system accepted the result after callback matching.
timeout_at When the run was marked late before a callback arrived.
current_state The visible state such as callback_received, duplicate_ignored, completed_after_timeout, or manual_review.
5. Suggested check
Match first, ignore exact duplicates, and keep late results visible
A callback checklist works best when the receiver treats callback matching as its own boundary check instead of folding it into a broad workflow assumption.
sent_to_clay -> waiting_for_result -> callback_received -> delivered_downstream / duplicate_ignored / completed_after_timeout -> manual_review- Match on run_id and source_event_id first before any downstream action.
- Use payload_hash to ignore exact duplicate callbacks without losing the original callback history.
- If callback_received_at arrives after timeout_at, keep completed_after_timeout visible instead of pretending the run completed normally.
- Track destination_status separately from callback_received_at so callback matching and delivery confirmation stay distinct.
- Move unmatched, late, or ambiguous callbacks into manual_review instead of guessing with replay.
- Keep the callback checklist narrow to the handoff boundary rather than the full GTM workflow.
6. No GTM logic required
The callback checklist can stand on its own
You do not need to expose lead routing, scoring, or sales process details to check whether a returned Clay callback is safe to advance.
- No lead scoring rules are needed to match a Clay callback to the original run.
- No routing logic is needed to decide whether an exact duplicate callback should be ignored.
- No sales assignment model is needed to keep completed_after_timeout visible.
- No full GTM workflow required. Clay Relay only checks the handoff boundary.
7. Synthetic example
Original send, matching callback, duplicate ignored, and late callback
Every value below is synthetic. The goal is to show how the callback checklist behaves with a normal match, an exact duplicate callback, and a late callback after timeout.
{
"run_id": "cr_run_20260630_801",
"source_event_id": "evt_synthetic_801",
"sent_to_clay_at": "2026-06-30T10:00:00Z",
"current_state": "waiting_for_result"
}{
"run_id": "cr_run_20260630_801",
"source_event_id": "evt_synthetic_801",
"callback_received_at": "2026-06-30T10:02:11Z",
"payload_hash": "sha256:synthetic-callback-801",
"destination_status": "accepted",
"current_state": "delivered_downstream"
}{
"run_id": "cr_run_20260630_801",
"source_event_id": "evt_synthetic_801",
"callback_received_at": "2026-06-30T10:02:18Z",
"payload_hash": "sha256:synthetic-callback-801",
"destination_status": "accepted",
"current_state": "duplicate_ignored"
}{
"run_id": "cr_run_20260630_802",
"source_event_id": "evt_synthetic_802",
"timeout_at": "2026-06-30T10:05:00Z",
"callback_received_at": "2026-06-30T10:06:42Z",
"payload_hash": "sha256:synthetic-callback-802",
"destination_status": "held",
"current_state": "completed_after_timeout"
}9. What Clay Relay would track
The checklist layer is about correlation, duplicate prevention, and late-state visibility
Original send identity
Whether run_id, source_event_id, and sent_to_clay_at define one open callback boundary clearly.
Callback received
Whether callback_received_at arrived for the right run and stayed tied to the original handoff.
Duplicate callback ignored
Whether an exact repeated payload_hash was dropped safely as duplicate_ignored.
completed_after_timeout
Whether a late callback stayed visible as completed_after_timeout rather than overwriting timeout history.
Destination status
Whether the next system accepted the matched callback result after the handoff checklist passed.
Manual review
Whether ambiguous or unsafe callback outcomes were held for review before replay or retry happened.
10. CTA
Check the callback handoff boundary before it advances the wrong state
We can review one Clay callback handoff, show where run_id matching, payload_hash duplicate prevention, completed_after_timeout visibility, or destination_status is still fragile, and keep the review scoped to that boundary.