For Zapier real estate lead response automation, build the recovery path alongside the happy path: receive the inquiry, validate its fields, identify the intended action, check current eligibility, request the action, and record its external identifier. When a call request times out, investigate whether it happened before sending another request. When only CRM logging fails, repair the log rather than restart outreach.
This is a proposed implementation pattern for a brokerage operations lead and their technical implementer—not a tested Callion integration or a ready-made Zap template. It addresses replay and partial failures; the broader lead-response automation guide covers workflow architecture.
Establish what arrived before sending anything
For a webhook-based source, begin with Webhooks by Zapier and select the appropriate trigger. Catch Hook parses incoming request data; Catch Raw Hook preserves the unparsed body and includes headers. See Zapier's webhook setup instructions. Confirm that your actual source supports the chosen delivery method; do not assume every portal offers the same connection.
Map a source event identifier, source name, original timestamp, intended owner and the information needed for the requested response. Use synthetic records while configuring. Keep credentials and unnecessary personal information out of test payloads and troubleshooting screenshots.
Do not use a successful HTTP response as your end-to-end acceptance test. A turned-off or deleted Catch Hook Zap eventually returns 404, but the change can take several hours, during which it can still return 200. Zapier documents that transition. Check the matching run and downstream result as separate evidence.
Name the action, not just the person
Use three distinct identifiers in your design:
- Contact ID: the person or CRM contact.
- Inquiry ID: this particular request, retained across delivery retries.
- Action key: the one intended operation, such as
source:event-418:first-call:v1.
That key is an illustrative format, not a required Zapier field. Do not derive it from a fresh timestamp on each retry. A later, genuinely new inquiry should retain its own identity; deciding whether it warrants more outreach is a separate business decision.
Ask the implementer to reserve the action atomically in a durable ledger, rather than use an unprotected “search, then create” sequence. PostgreSQL can enforce uniqueness across a combination of columns; ordinary unique indexes permit multiple nulls by default. A PostgreSQL implementation should therefore require non-null identifying fields as well as the appropriate unique constraint. PostgreSQL 17 documentation supports that database mechanism, not an end-to-end exactly-once guarantee.
A reservation is not proof of completion. Store a state such as reserved, confirmed, rejected or unknown, together with the external request ID and the evidence for any transition. Do not automatically clear an old reservation: a worker might have completed the external action before losing its connection.
Choose the correct replay operation
Replaying errored steps from Zap history does not replay previously successful steps, and Filter and Paths steps are not replayed. Replaying an entire run from the editor creates a new run and repeats every step, including Filter and Paths using the current published workflow. These are different operations in Zapier's replay documentation.
Consequently, place the final current-eligibility check inside the component that executes outreach, not solely in an earlier Filter. Have that component recheck the team's approved stop, ownership and contact rules on every attempt. This is an engineering safeguard, not a statement of which calls are legally permitted.
Use this original recovery table as an incident worksheet. The rows are proposed operating decisions, not claims that Zapier implements the ledger automatically.
| Observed evidence | Recovery decision | Evidence to retain |
|---|---|---|
| Same inquiry/action arrives again; ledger has a confirmed external request | Reuse the recorded result; do not start another call | Action key, original external ID, duplicate arrival time |
| Validation rejected the payload before any external request | Correct the mapping, then process the intended action under its existing identity | Rejected fields, corrected input, proof no request was sent |
| Provider accepted the call request; CRM note failed | Repair only the note, using its own stable identity | Provider ID and the CRM write error |
| Request timed out; provider outcome is unknown | Reconcile using provider records or documented idempotent retry; otherwise assign a human | Request time, action key, lookup result and unresolved status |
| Eligibility changed while a retry was waiting | Stop the action and record the current decision | Current rule outcome and responsible owner |
“Accepted” here means the provider accepted a request, not that the prospect answered.
Check the destination's contract before enabling retries
Stripe documents an API that retains the first result for an idempotency key and returns that result on a repeated request with the same key. Its documentation also limits key retention and describes parameter checks. This is an example of an explicit idempotency contract, not a reason to add Stripe to a lead workflow or assume a calling provider accepts the same header.
For your actual destination, document supported operations, key lifetime, response meaning, status lookup and behavior when parameters change. If those guarantees are absent, leave ambiguous outcomes in a human-owned recovery queue. A database marker alone cannot resolve whether a remote call happened.
Prove recovery with a controlled test
Before contacting real prospects, use a sandbox or a harmless stub in place of the calling action. Run these acceptance cases and keep the observed results:
- Deliver the same inquiry twice simultaneously. Expect one intended action to be reserved, with the duplicate recognized.
- Simulate provider acceptance followed by a lost response. Expect reconciliation or an unknown state—not an unexamined second request.
- Fail CRM logging after a confirmed action. Expect the repair to touch only the log.
- Change the eligibility decision before retry. Expect the executor to stop.
- Replay a whole run deliberately. Expect action-level protection to recognize prior work even though the workflow runs again.
These are proposed tests, not results from a Callion customer deployment. Name a person who checks unknown outcomes, set an internal response deadline and record how the queue is cleared. Use the lead-response plan to assign that responsibility. For source-specific context, browse the lead sources and integrations hub.
Start with one source and one action. Expand only after the implementer can explain both how a successful response is recorded and how an uncertain response is prevented from becoming duplicate outreach.