Delivery history and recovery

Find the outbound attempt for a specific lead, read the recorded state and HTTP context, and decide whether the next step is configuration repair, provider verification, or an eligible Resend. Recovery creates a new delivery and never rewrites the original.

Why it matters

Lead-first history connects an external response to the HoneyFalcon lead and connector that produced it. This turns a provider failure into a traceable operations task while keeping response detail bounded and credentials out of the record.

Where to work

Open Company -> Connectors, select Edit for the relevant connector, and scroll to Delivery history. Use State and Date range to narrow the table before opening any eligible Resend action.

Steps

1. Open the connector that was expected to deliver the lead.
2. Filter by State and Date range, then identify the row by Lead, Email, Lead ID, or Delivery ID.
3. Read State, Response, Created, and the bounded response detail before changing configuration.
4. For a configuration problem, correct and save the connector; for a destination-side issue, verify the provider account separately.
5. If Resend is available for an eligible failure, review the duplicate warning, enter a specific Reason, and select Create new delivery only when another attempt is justified.
6. Trace the new Delivery ID separately and verify the destination result without changing the original attempt.

See it in HoneyFalcon

Filter the read-only delivery history and identify the relevant lead before investigating a recorded result.

From recorded result to controlled action

Locate the exact attempt

Delivery history starts with lead identity, then shows Lead ID, State, Response, Created, Delivery ID, and any available action. Use the visible identity for routine support and the identifiers when two records look similar.

State and Date range apply to the current connector's history. Clear the filters to return to the full visible interval.

Interpret the state at the HoneyFalcon boundary

Queued, in-progress, or retryable work has not reached a terminal result and should not be resent manually. Delivered means the provider returned one of the connector's configured Successful HTTP statuses.

Delivered does not prove that the external record has the intended final values. Check the destination when that semantic confirmation matters.

Choose the corrective path

Use the bounded, redacted response to distinguish an authentication problem, invalid destination field, unexpected status, or temporary provider condition. Correct the visible draft only when the configuration is wrong, then Save changes before it can be used by real delivery.

Keep the connector unchanged when the evidence points to a provider account or availability issue.

Use Resend only for an eligible failure

When HoneyFalcon displays Resend, the confirmation explains that the action uses the current connector configuration and current lead data. It requires a Reason and creates a new Delivery ID.

The original attempt remains unchanged. Because the destination may already have processed the first request, the new delivery can create a duplicate.

Share safe support evidence

Record the connector name, Lead ID, Delivery ID, timestamp, visible state, HTTP status, and bounded message. Do not share the complete credential, Authorization header, destination URL containing a secret, or raw payload with personal data.

The delivery is understood when

• The filtered row matches the intended lead, connector, and time window.
• The visible state and bounded response identify the next configuration, provider, or support action without exposing a secret.
• Delivered is verified at the destination when the external effect matters.
• Any eligible Resend has a recorded reason, a separate Delivery ID, and no mutation of the original evidence.

Continue learning

• Start from: For operations - start here
• Previous: Edit and test safely
• Next: Generic webhook connector