1. Boundary
External push into Clay to result returned and destination accepted
This boundary starts when an external API or source system pushes a record toward a Clay table and ends only when the returned enrichment result is delivered downstream or moved into a visible exception state such as timed_out or manual_review.
2. Question
Did the result return and did the next system confirm delivery?
The useful question is not whether the push worked. It is whether callback return, destination_status, timeout detection, and replay safety all stayed visible for the same run.
3. Risk
Push-to-table reliability usually breaks after the first POST
Push succeeded, but no result returned
A Clay external API push to table can accept the record while the useful enrichment result never comes back through the expected callback path.
Result returned, but delivery was not confirmed
A returned payload is not the same thing as destination accepted. destination_status has to confirm the next safe state.
timed_out exists nowhere
Without an explicit timed_out state, the push can fail silently after the first handoff while operators assume the record is still being processed.
Retry or replay duplicates side effects
If retry_count, payload_hash, and destination_status are unclear, a replay can create duplicate writes, alerts, or downstream objects.
4. Minimum fields
You need run state, timestamps, and replay hints
source_event_id The source system identity that should still match after the record is pushed toward Clay.
run_id The internal run identity for one push-data-to-Clay-table handoff.
received_at When the external API or source system first reached the receiver.
sent_to_clay_at When the receiver actually pushed the record toward the Clay table.
waiting_for_result The open state after the push succeeds and before a result returns.
callback_received_at When the webhook callback or return payload came back from Clay.
destination_status Whether the next system accepted the returned enrichment result.
timed_out Whether the result-return boundary expired before a callback arrived.
retry_count How many controlled retries or replays were attempted after an exception.
payload_hash A stable hash that helps identify duplicate returned payloads during replay checks.
5. Suggested check
Keep the result-return boundary visible from receive to replay
A Clay external API push to table is easier to trust when the receiver stores one run record, keeps waiting_for_result visible, and checks destination acceptance before any replay happens.
received -> sent_to_clay -> waiting_for_result -> callback_received -> delivered_downstream / timed_out -> manual_reviewif payload_hash matches a previously delivered callback or retry_count exceeds the safe limit: hold_for_manual_review- Persist source_event_id and run_id when the external API request is received.
- Record received_at and sent_to_clay_at as separate timestamps so the first handoff stays visible.
- Move the run into waiting_for_result immediately after the push to the Clay table succeeds.
- Accept the callback only when it matches the original source_event_id and run_id pair.
- Track destination_status separately from callback_received_at so result returned and destination accepted are different states.
- Use payload_hash and retry_count to review replay safety before resending the handoff.
6. No GTM logic required
This handoff can be checked without exposing the wider implementation
You do not need to reveal the full system around Clay to verify whether this result-return boundary closed safely. The handoff can be reviewed on its own.
- No lead scoring logic is needed to know whether the result returned.
- No routing rules are needed to know whether destination_status ever became accepted.
- No sales process details are needed to know whether timed_out or manual_review is still open.
- No full GTM workflow required. Clay Relay only checks the handoff boundary.
7. Synthetic example
Synthetic push-data-to-Clay-table run
Every value below is synthetic. The point is to show how a push-data-to-Clay-table boundary stays visible without real customer data, private Clay table rows, or private webhook details.
{
"event_type": "lead.created",
"source": "external_api",
"source_event_id": "evt_synthetic_push_701",
"email": "maya@example-push.test",
"domain": "example-push.test",
"company": "Example Push Co",
"received_at": "2026-06-30T09:10:00Z",
"run_id": "cr_run_20260630_701"
}{
"run_id": "cr_run_20260630_701",
"source_event_id": "evt_synthetic_push_701",
"received_at": "2026-06-30T09:10:00Z",
"sent_to_clay_at": "2026-06-30T09:10:03Z",
"waiting_for_result": true,
"callback_received_at": "2026-06-30T09:12:18Z",
"destination_status": "accepted",
"timed_out": false,
"retry_count": 0,
"payload_hash": "sha256:synthetic-push-701"
}{
"run_id": "cr_run_20260630_702",
"source_event_id": "evt_synthetic_push_702",
"received_at": "2026-06-30T09:14:00Z",
"sent_to_clay_at": "2026-06-30T09:14:04Z",
"waiting_for_result": false,
"callback_received_at": null,
"destination_status": "not_attempted",
"timed_out": true,
"retry_count": 1,
"payload_hash": null,
"current_state": "manual_review"
}9. What Clay Relay would track
The boundary layer is about visibility, delivery confirmation, and safe replay
Request received
Whether received_at, source_event_id, and run_id were created before the record disappeared into Clay.
Clay table handoff started
Whether sent_to_clay_at proves the record actually left the receiver and reached the push boundary.
Result returned
Whether callback_received_at exists for the same run that entered waiting_for_result.
Destination accepted
Whether destination_status confirms the next safe state after the callback returned.
Timed out and reviewed
Whether timed_out moved the run into a visible exception state instead of leaving it open silently.
Replay safety
Whether payload_hash and retry_count show that retry or replay will recover the handoff without duplicating it.
10. CTA
Check the push-to-Clay result-return boundary before it fails silently
We can review one Clay external API push to table boundary, show where callback, destination_status, timeout, payload hash checks, and replay safety are still fragile, and keep the review scoped to that handoff only.