1. Boundary
Clay callback to the original run and then to the next destination
This boundary starts when the original run is sent toward Clay and ends only after the returned callback is matched, duplicate risk is checked, and downstream delivery either succeeds or becomes a visible exception.
2. Question
Did the returned Clay result match the original run safely?
A callback boundary is healthy only when the returned result can be matched to the correct run, duplicate callbacks are ignored safely, and the next destination still accepts the handoff.
3. Risk
Matching errors, duplicates, and late completion are the real failure modes
Wrong callback matched to the run
If the callback cannot be tied back to the original run cleanly, the wrong row or destination can be updated.
Duplicate callback triggers duplicate delivery
Without a safe duplicate rule, the same callback can produce a second CRM write, alert, or webhook send.
Completed-after-timeout is hidden
A late result should not erase the fact that timeout already happened. It should become a visible completed_after_timeout state.
Callback matched, but destination still failed
A good callback correlation result still needs a separate downstream acceptance check.
4. Minimum fields
A callback boundary needs correlation fields and state
run_id The primary key for the original send and the returned callback.
source_event_id The upstream event identity that should still match after the callback returns.
sent_to_clay_at When the original run was handed off toward Clay.
callback_received_at When the callback returned to the receiver.
payload_hash A stable hash that helps ignore an exact duplicate callback 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 run state after matching, timeout, or replay logic runs.
5. Suggested check
Match first, then handle duplicates, timeout history, and delivery
Keep one open run record, match the callback against that record, and update state based on whether the callback is on time, duplicate, late, or followed by destination failure.
sent_to_clay -> waiting_for_result -> callback_received -> delivered_downstream / timed_out -> completed_after_timeout -> manual_reviewif run_id + source_event_id + payload_hash match an existing callback record: duplicate_ignored- Create the run_id before sending anything toward Clay.
- Persist source_event_id and sent_to_clay_at with the original run.
- Accept the callback only when run_id and source_event_id match the open run.
- Use payload_hash to ignore an exact duplicate callback safely.
- If the callback arrives after timeout, move the run to completed_after_timeout instead of pretending the timeout never happened.
- Track destination_status separately so callback_received and delivered_downstream stay different states.
6. No GTM logic required
The callback boundary is narrower than the workflow around it
You do not need the surrounding GTM logic to check whether a callback matched, arrived late, or should be ignored as a duplicate. The callback boundary stands on its own.
- No lead scoring rules are needed to match a callback to the original run.
- No routing logic is needed to decide whether a duplicate callback should be ignored.
- No sales assignment model is needed to record completed_after_timeout safely.
- No full GTM workflow required. Clay Relay only checks the callback boundary.
7. Synthetic example
Synthetic send, callback, and late completion example
Every value below is synthetic. The point is not the data itself. The point is how the returned callback relates back to the original run and how a late result is handled safely.
{
"run_id": "cr_run_20260629_401",
"source_event_id": "evt_synthetic_401",
"sent_to_clay_at": "2026-06-29T11:00:00Z",
"email": "alex@example-callback.test",
"domain": "example-callback.test"
}{
"run_id": "cr_run_20260629_401",
"source_event_id": "evt_synthetic_401",
"callback_received_at": "2026-06-29T11:02:14Z",
"payload_hash": "sha256:synthetic-match-401",
"destination_status": "accepted",
"current_state": "delivered_downstream"
}{
"run_id": "cr_run_20260629_401",
"timeout_at": "2026-06-29T11:01:30Z",
"callback_received_at": "2026-06-29T11:03:05Z",
"payload_hash": "sha256:synthetic-match-401",
"duplicate_callback": "ignored_on_repeat",
"current_state": "completed_after_timeout",
"delivery_action": "held_for_manual_review"
}9. What Clay Relay would track
A good callback layer keeps match history and exception history visible
Original send identity
The run_id, source_event_id, and sent_to_clay_at values that define the open handoff.
Callback match result
Whether the callback matched one open run cleanly or needs manual review.
Duplicate callback ignored
Whether an exact repeated callback was dropped safely using payload_hash or equivalent logic.
Completed-after-timeout
Whether a late callback was recorded as a late completion instead of silently overwriting timeout history.
Destination acceptance
Whether the matched callback actually reached the next accepted destination.
Replay safety
Whether the run can be retried without creating a duplicate delivery.
10. CTA
Check the callback boundary before duplicates or late results confuse the run
We can review one Clay callback boundary, show where matching, duplicate handling, timeout history, or downstream delivery is still fragile, and keep the review scoped to that handoff only.