A buyer says they didn't receive a lead. Your Zapier history says the task ran. The buyer's CRM shows nothing. This is the diagnostic gap that costs agencies time, buyer trust, and — if it happens repeatedly — the buyer relationship itself.
Debugging lead delivery failures requires knowing exactly what your router captured about each delivery attempt. The debugging speed is proportional to the quality of your delivery logs.
The three-layer delivery failure model
Lead delivery failures happen at one of three layers, and the fix depends on which layer you're looking at:
- Your router's outbound layer: Did the HTTP request leave your system? Network timeouts, DNS failures, and TLS errors show up here. These are rare but prevent the request from reaching the buyer at all.
- The buyer's endpoint layer: Did the request reach the buyer's server? The HTTP status code answers this. 4xx means the server rejected your request (authentication, payload validation, wrong URL). 5xx means the server received it but failed internally (overload, CRM outage, application error).
- The buyer's CRM internal layer: Did the CRM process the lead after the endpoint accepted it? Some CRMs return 200 to your router but fail the lead internally — it never appears in the CRM's lead list. This layer is invisible to your router unless the CRM returns a failure body inside a 200 response.
Most debugging time is wasted when the layer is unidentified. Knowing the HTTP status code immediately narrows to layer 2 or 3 and rules out layer 1.
Reading HTTP status codes for delivery diagnosis
The HTTP status code from the buyer's endpoint is the fastest diagnostic signal:
- 200-299: The endpoint accepted the request. If the buyer still can't find the lead, the failure is inside their CRM (layer 3). Check the response body for an embedded error message.
- 401 / 403: Authentication failure. The API key or auth header is wrong or expired. Fix: update credentials in your buyer configuration and re-deliver the affected leads.
- 404: Wrong URL. The endpoint moved or was misconfigured. Fix: update the buyer's delivery URL.
- 422: Payload validation failed. Your lead is missing a required field or a field has the wrong format. Check the response body for the field name. Fix: update your field mapping for this buyer.
- 500-503: Server error or downtime on the buyer's end. Transient — retry with backoff. If errors persist past 30 minutes, notify the buyer their endpoint is down.
- Timeout: The request reached the server but no response came back within the timeout window. Treat as 5xx — retry.
What a useful delivery log contains
A delivery log that supports fast debugging captures: lead ID, buyer ID, attempt number, attempt timestamp, outbound payload, HTTP status code, HTTP response body (truncated if large), retry count, and final status. With all of these, the diagnosis for any single delivery failure takes under two minutes.
Zapier's Task History captures attempt timestamps and error reasons but doesn't expose the full response body from the buyer's endpoint in a queryable format. Finding a specific lead's delivery attempt requires knowing the approximate time and Zap name, then clicking through multiple task history entries. This works for occasional debugging but doesn't scale when you're investigating 50 failed deliveries per day.
Custom routers vary widely. Many log at the job or Zap level (did the batch run?) without per-lead granularity. Without per-lead logs, you can't tell which specific leads failed in a batch of 200 — only that some percentage did.
Comparing debugging tools across platforms
| Platform | Per-lead delivery log | HTTP response body visible | Retry history | Dead-letter queue |
|---|---|---|---|---|
| Sheets + Zapier | No (per-task only) | Partial | No | No |
| LeadMove | Yes | Yes | Yes | Yes |
| LeadProsper | Yes | Yes | Yes | Yes |
| Custom build | Only if built | Only if built | Only if built | Rarely built |
The dead-letter queue as a safety net
Some failures don't self-resolve within a retry window. If a buyer's endpoint is down for 6 hours, leads that arrived during that window exhaust their retries and need somewhere to go. A dead-letter queue (DLQ) holds these leads in a visible, actionable state — not lost, not silently dropped, but parked and waiting for either manual re-delivery or automated re-attempt when the endpoint recovers.
Without a DLQ, exhausted retries mean permanent loss. With a DLQ, a 6-hour endpoint outage becomes a 6-hour delay, resolved by bulk-redelivering the DLQ contents once the buyer's system is back up. This distinction matters most during buyer CRM migrations, maintenance windows, and API key rotations — exactly the times when endpoint downtime is most likely.
Proactive monitoring vs reactive debugging
Debugging is reactive. Monitoring prevents the need to debug. Useful delivery monitoring includes: per-buyer delivery success rate (alert if it drops below 95%), per-buyer failure count in the last hour, latency trends (rising latency often precedes outages), and DLQ size. An alert when buyer A's success rate drops to 80% catches an endpoint problem before the buyer notices missing leads and contacts you.
Good delivery logs don't prevent failures — they make failures recoverable before they damage buyer relationships. The faster you can pinpoint a failure, the faster you can fix it and re-deliver the affected leads.