Clay callback handoff checklist
Match run_id, source_event_id, duplicate callbacks, late callbacks, and destination_status before moving the run forward.
Clay Failure Boundary Library
Failure-boundary checks for Clay enrichment handoffs.
Clay Relay helps teams check whether a Clay enrichment handoff reached the next safe state: callback returned, timeout fired, downstream delivery accepted, duplicate ignored, or retry handled safely.
No full GTM workflow required. Clay Relay only checks the handoff boundary.
Boundary-first
The unit is a boundary, not a workflow.
A source tool may be the search doorway, but the page body should focus on one Clay handoff boundary: the return path, timeout state, delivery confirmation, duplicate handling, or replay safety.
- Boundary
- Clay callback -> receiving system
- Question
- Did the callback return and match the original run?
- Risk
- Silent failure, late completion, duplicate delivery, or wrong record match.
- Suggested check
- Keep the run in waiting_for_result until a matching callback arrives or timeout fires.
Current boundary examples
Start with the core callback, timeout, delivery, and entry-point boundaries.
Clay enrichment timeout boundary
Make waiting_for_result, timed_out, Slack timeout alerts, and replay safety visible when the result does not return in time.
Clay downstream delivery confirmation
Track the boundary between callback_received and delivered_downstream so destination acceptance is never assumed.
Example inbound Clay callback boundary
A synthetic example showing how a returned Clay result should match the original run and keep completed_after_timeout visible.
Trial signup enrichment boundary
After a Stripe or Paddle event is sent toward Clay, did the enriched result return and reach the next system?
External API push into Clay boundary
After a record is pushed toward Clay, is there a visible state for waiting, returned, delivered, timed out, or retried?
Clay webhook monitoring boundary
Monitor callback return, timeout detection, downstream delivery status, and alerts tied to real run state.
Library shelves
How the library should expand.
Boundary Guides
One handoff, one question, one risk, minimum fields, and a suggested check.
Run-State Schemas
Minimum fields such as run_id, source_event_id, callback_received_at, timeout_at, destination_status, and retry_count.
Integration Boundary Entry Points
Source-tool search pages that still focus on result return, timeout, retry, and delivery confirmation.
Synthetic Boundary Examples
Synthetic payloads and run logs that show the boundary without exposing real GTM logic or private Clay data.
Minimum fields
A boundary check needs identifiers and state, not private GTM logic.
The minimum fields should make a run traceable without requiring lead scoring rules, routing logic, CRM workflow design, or sales assignment details.
run_idsource_event_idsent_to_clay_atcallback_received_attimeout_atdestination_statusretry_count Review one boundary
Check one Clay handoff boundary before adding more routing, alerts, or replay logic.
Share a narrow handoff question: callback, timeout, result return, delivery confirmation, duplicate callback, late result, manual review, or retry / replay safety.