1. Boundary
Trial signup event sent toward Clay to result returned and accepted
This boundary starts when a Stripe or Paddle trial signup event is sent toward Clay and ends only when the enrichment result is either delivered downstream or moved into a visible exception state such as timed_out or manual_review.
2. Question
Did the enriched result return and reach the next safe state?
The useful question is not whether the signup event was received. It is whether the callback returned for the same run, whether delivered_downstream actually happened, and whether timeout or replay stayed visible if something broke.
3. Risk
Trial signup enrichment can fail silently after the first handoff
Result never returned
A Stripe trial signup to Clay or Paddle trial signup to Clay can send successfully while the enrichment result never comes back through the expected callback path.
Duplicate event or duplicate callback
A repeated signup event or repeated callback can create duplicate CRM writes, duplicate Slack alerts, or duplicate routing unless the boundary has duplicate prevention.
Timeout happened but nobody saw it
Without a visible timed_out state, trial signup enrichment can fail silently while the surrounding system keeps waiting.
Result returned but next safe state never happened
A callback can arrive while delivered_downstream is still false, which means the handoff is not actually complete yet.
4. Minimum fields
You need run state and timestamps, not a full playbook
source_event_id The Stripe or Paddle trial signup event identity that should stay stable across the handoff.
run_id The internal run identity that ties the signup event, Clay handoff, callback, and replay decisions together.
sent_to_clay_at When the trial signup enrichment payload was actually forwarded toward Clay.
waiting_for_result The open run state after the event is sent toward Clay and before a result returns.
callback_received_at When the Clay callback arrived with the enrichment result.
timed_out Whether the expected result failed to return inside the chosen boundary window.
delivered_downstream Whether the next system accepted the returned enrichment result.
manual_review Whether the run still needs a person before retry or replay is safe.
5. Suggested check
Keep the boundary visible from send to callback, timeout, or review
A trial signup enrichment boundary is easier to trust when the receiver keeps one stable run record and moves that run through explicit states instead of implicit assumptions.
signup_received -> sent_to_clay -> waiting_for_result -> callback_received -> delivered_downstream / timed_out -> manual_reviewif source_event_id is already linked to a closed run or the callback repeats the same run_id: duplicate_ignored- Create run_id when the Stripe or Paddle signup event is first received.
- Persist source_event_id before sending the enrichment webhook toward Clay.
- Move the run into waiting_for_result immediately after sent_to_clay_at is recorded.
- Accept the callback only when it matches the open run_id and source_event_id pair.
- Ignore duplicate event or duplicate callback attempts once the same run is already closed or safely matched.
- Move unresolved runs to manual_review after timed_out instead of guessing with a blind replay.
6. No GTM logic required
This boundary can be checked without exposing the rest of the system
You do not need to reveal lead scoring, routing, or sales process details to know whether a Clay enrichment handoff closed safely. The boundary stands on its own.
- No lead scoring rules are needed to know whether the result returned.
- No CRM routing logic is needed to know whether delivered_downstream happened.
- No sales assignment model is 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 trial signup enrichment run
Every value below is synthetic. The example shows how a trial signup enrichment boundary stays visible without using real customer data, real Clay table data, or private webhook details.
{
"event_type": "trial_signup.created",
"source": "stripe_or_paddle",
"source_event_id": "evt_synthetic_trial_601",
"signup_email": "alex@example-trial.test",
"signup_domain": "example-trial.test",
"plan": "growth_trial",
"run_id": "cr_run_20260630_601"
}{
"run_id": "cr_run_20260630_601",
"source_event_id": "evt_synthetic_trial_601",
"sent_to_clay_at": "2026-06-30T08:00:04Z",
"waiting_for_result": true,
"callback_received_at": "2026-06-30T08:02:11Z",
"timed_out": false,
"delivered_downstream": true,
"manual_review": false
}{
"run_id": "cr_run_20260630_602",
"source_event_id": "evt_synthetic_trial_602",
"sent_to_clay_at": "2026-06-30T08:04:03Z",
"waiting_for_result": false,
"callback_received_at": "2026-06-30T08:08:30Z",
"timed_out": true,
"delivered_downstream": false,
"manual_review": true,
"note": "completed_after_timeout held for replay safety review"
}9. What Clay Relay would track
The boundary layer is about visibility, duplicate prevention, and safe replay
Event received and normalized
Whether the Stripe or Paddle signup event produced one stable source_event_id and run_id.
Clay handoff started
Whether sent_to_clay_at is present and the enrichment webhook actually left the receiver.
Result returned
Whether callback_received_at exists for the same run that entered waiting_for_result.
Duplicate prevention
Whether a duplicate event or duplicate callback was ignored safely instead of writing downstream twice.
Delivered downstream
Whether the next destination accepted the returned enrichment result cleanly.
Manual review and replay safety
Whether timed_out or delivery-failed runs moved into manual_review before retry or replay happened.
10. CTA
Check the trial signup handoff boundary before it fails silently
We can review one Stripe or Paddle trial signup to Clay boundary, show where callback, timeout, duplicate prevention, delivered_downstream, and replay safety are still fragile, and keep the review scoped to that handoff only.