1. Boundary
Returned Clay callback to downstream destination acceptance
This boundary starts when the Clay callback is received and ends only when the next destination confirms acceptance or the run becomes a visible exception state such as destination_failed or manual_review.
2. Question
Did the next system actually accept the returned result?
The useful downstream delivery question is not whether the callback returned. It is whether the next system accepted the enriched result, rejected it, or left the outcome too ambiguous for safe replay.
3. Risk
Callback success and delivery success are different boundary outcomes
Callback returned but the next system never accepted it
A Clay callback returning is useful only if the next destination confirms acceptance. Otherwise the handoff is still open.
destination_failed is hidden behind callback_received
If callback_received_at is treated like completion, rejected or failed downstream writes disappear from view and the run looks healthier than it is.
destination_status stays unknown
When the receiver cannot tell whether the next system accepted or rejected the result, replay safety and manual review become the real boundary question.
Blind retry creates duplicate side effects
Retry or replay without a clear destination outcome can create duplicate CRM writes, duplicate webhook sends, or conflicting downstream records.
4. Minimum fields
Delivery confirmation needs response evidence and state
run_id The internal run identity that ties the returned callback to one downstream delivery attempt.
source_event_id The upstream event identity that should still match when delivery is attempted.
callback_received_at When the Clay result returned before any downstream write was attempted.
destination_name The specific next system that should accept the enriched result.
delivery_attempted_at When the receiver actually attempted to send the result to the downstream destination.
destination_status Whether the next system accepted, rejected, failed, or returned an unknown delivery outcome.
destination_response_code The response evidence from the downstream system when the delivery attempt happened.
delivered_downstream A boolean or equivalent state that becomes true only after confirmed acceptance.
retry_count How many controlled retries or replays have been attempted after a downstream delivery exception.
current_state The visible run state such as callback_received, delivered_downstream, destination_failed, or manual_review.
5. Suggested check
Confirm destination acceptance before closing the run
A downstream delivery boundary is safer when the system records one explicit delivery attempt, one explicit destination outcome, and one visible review state before any replay is allowed.
callback_received -> delivery_attempted -> delivered_downstream / destination_failed / destination_unknown -> manual_review- Track callback_received_at separately from destination_status so callback return and delivery confirmation stay distinct.
- Record delivery_attempted_at and destination_response_code every time the next system is contacted.
- Only mark delivered_downstream when the downstream destination confirms acceptance explicitly.
- If destination_status is rejected, failed, or unknown, move the run to destination_failed or manual_review before any retry or replay.
- Hold retry_count steady until an operator reviews the downstream outcome and decides whether replay is safe.
- Keep this page focused on the callback_received to delivered_downstream boundary, not the full GTM workflow.
6. No GTM logic required
Delivery confirmation can be reviewed without exposing the wider system
You do not need to reveal lead routing, scoring, or CRM workflow details to know whether a downstream destination accepted the result. This delivery boundary stands on its own.
- No lead scoring rules are needed to know whether the next system accepted the returned result.
- No routing logic is needed to know whether destination_status is accepted, rejected, failed, or unknown.
- No sales assignment model is needed to hold a rejected downstream write for manual_review.
- No full GTM workflow required. Clay Relay only checks the handoff boundary.
7. Synthetic example
Callback returned, accepted, rejected, unknown, and retry held
Every value below is synthetic. The example shows how callback receipt stays separate from destination acceptance, rejection, unknown delivery, and replay decisions.
{
"run_id": "cr_run_20260630_1001",
"source_event_id": "evt_synthetic_1001",
"callback_received_at": "2026-06-30T12:00:14Z",
"destination_name": "crm_synthetic",
"current_state": "callback_received"
}{
"run_id": "cr_run_20260630_1001",
"delivery_attempted_at": "2026-06-30T12:00:19Z",
"destination_status": "accepted",
"destination_response_code": 202,
"delivered_downstream": true,
"current_state": "delivered_downstream"
}{
"run_id": "cr_run_20260630_1002",
"delivery_attempted_at": "2026-06-30T12:02:41Z",
"destination_status": "rejected",
"destination_response_code": 422,
"delivered_downstream": false,
"current_state": "destination_failed"
}{
"run_id": "cr_run_20260630_1003",
"delivery_attempted_at": "2026-06-30T12:04:07Z",
"destination_status": "unknown",
"destination_response_code": null,
"delivered_downstream": false,
"current_state": "manual_review"
}{
"run_id": "cr_run_20260630_1003",
"retry_count": 0,
"current_state": "manual_review",
"replay_allowed": false,
"reason": "downstream delivery outcome unresolved"
}9. What Clay Relay would track
The delivery layer is about acceptance evidence and safe recovery
Callback returned
Whether callback_received_at exists before any downstream delivery is marked complete.
Delivery attempted
Whether delivery_attempted_at and destination_name prove that the next system was actually contacted.
Destination accepted
Whether destination_status and destination_response_code confirm delivered_downstream safely.
Destination failed
Whether rejected, failed, or unknown delivery outcomes stayed visible instead of hiding under callback_received.
Manual review
Whether uncertain downstream outcomes were held for review before retry or replay happened.
Replay safety
Whether retry_count stayed controlled until the downstream delivery boundary was understood and safe to recover.
10. CTA
Check the downstream delivery boundary before callback success hides the failure
We can review one Clay downstream delivery boundary, show where callback receipt, destination acceptance, destination_failed handling, or replay safety is still fragile, and keep the review scoped to that handoff only.