Is a bridge miss a bug?

Sometimes, sometimes not. Bridge misses caused by archived workspaces, cross-account-disconnect timing, or prospect URL changes are by-design — the matcher's strict guards correctly refuse to bridge in ambiguous cases (we'd risk attributing the wrong send credit). Bridge misses caused by deploy races or matcher-logic gaps are bugs we iterate on. The trace data tells us which category each row falls into. Single-digit counts on your dashboard are normal background noise; sharp rises are worth investigating.

Will my follow-up still fire if a bridge miss happens?

Most of the time, yes — the recurring late-accept heal sweep (every 6 hours) catches bridge misses post-hoc by sweeping for prospects whose LinkedIn-side state shows them as accepted but whose linkedin_accepted_at column was never written. For each, we stamp late_accept_observed_at on a separate column and surface the row on the dashboard's Late Accepts tile with a manual Send follow-up CTA. So even if the real-time bridge missed, the recovery layer typically fires the follow-up within 6 hours.

Why doesn't the matcher just bridge based on name?

Name-based matching has a strict guard: it only fires when there is exactly ONE candidate matching the name. If two of your prospects share the same name (even by coincidence), the matcher rejects both rather than risk bridging the wrong one. This is the same direction the platform always errs — account safety wins, and bridging the wrong prospect would mean firing a follow-up message at someone who didn't accept your invite, which damages trust and risks LinkedIn's automation-detection treating it as a spam pattern.

What's the difference between a bridge miss and a late accept?

Bridge miss: workspace HAS running campaigns, matcher tried three strategies, none matched. Late accept: matcher DID find the prospect, but the prospect's workflow has already moved past wait_accept (timed out, condition_skipped, completed, or stopped). The bridge-miss case is about the matcher itself; the late-accept case is about workflow timing. Both surface on the same dashboard tile but represent different underlying conditions. See /documentation/what-is-a-late-accept for the late-accept side.

Can I see the diagnostic data for a specific bridge miss?

Yes — request a trace export from hello@warmysender.com with the webhook ID or the prospect's LinkedIn URL. The trace row includes which strategies were attempted, how many candidates each found, and why each strategy rejected its candidates. Engineering uses the same data to iterate on the matcher; sharing it with you closes the loop.

Does a bridge miss put my LinkedIn account at risk?

No, the opposite. The bridge matcher is read-only at the LinkedIn boundary — it never fires LinkedIn API calls during webhook handling, never increments your daily send count, never affects your ramp progress. The trace observability rows are pure database writes. The recurring heal sweep that catches bridge misses post-hoc also makes zero LinkedIn API calls; it stamps internal columns and enqueues follow-ups via the existing send pipeline (which respects all caps, ramps, cooldowns, and sending-window guards). Account safety is preserved at every layer.

How can I reduce bridge misses on my workspace?

Three things help: (1) prefer public-profile LinkedIn URLs (linkedin.com/in/handle) over Sales Navigator URLs at import time — public URLs resolve to member IDs deterministically, while Sales Nav URLs may not. (2) Keep your LinkedIn accounts connected — most cross-account bridge misses happen when one account drops mid-campaign. (3) Avoid renaming or restructuring campaigns mid-flight — the matcher uses workspace-scoped lookups, and structural changes during an open invite window can confuse the relaxed Strategy 3.

Are bridge misses correlated with specific LinkedIn account types?

Slightly — accounts using Sales Navigator are more likely to have prospect URLs that don't resolve to member IDs at enrollment time, which means more reliance on Strategy 2 (URL re-resolution) and Strategy 3 (relaxed name match). The matcher handles all three account types (free, Premium, Sales Nav, Recruiter) but the strategy distribution differs. Per-account dashboards show the bridge-miss rate broken out by account so you can spot a misbehaving setup.

What is a "bridge miss" and when does it happen?

What this page covers

If you've spoken to our support team and seen the term bridge miss, this page explains exactly what it means, what causes it, what we do about it, and how to tell whether one in your dashboard is a problem or a by-design event you can ignore. WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. This page is part of the LinkedIn Outreach pillar.

The short version:

What it is: a LinkedIn invite-acceptance webhook arrived from LinkedIn, but our matcher couldn't tie it to a specific prospect in any of your running campaigns.
Why it matters: if a real prospect accepted your invite and we couldn't bridge the webhook to them, your follow-up message to that prospect won't auto-fire. We have multiple safety nets (recurring heal sweeps, late-accept tolerance, manual fix-up CTAs) that catch most bridge misses, but the bridge matcher is the primary path and we want it to succeed for the most cases possible.
What we do: every bridge miss is logged with rich diagnostic data (which strategies the matcher tried, how many candidates each strategy found, why the chosen one was rejected). The dashboard surfaces the count for transparency, and our engineering team uses the diagnostic data to iterate on the matcher logic.

How the matcher (bridge) works

When you send a LinkedIn invite through a WarmySender campaign, we record the prospect's identifier (name, public LinkedIn URL, member ID once we have one) on a row in your campaign_prospects table. When LinkedIn delivers an invitation.accepted event to our LinkedIn integration, the event is forwarded to our webhook endpoint with the LinkedIn member ID of the person who accepted. Our matcher then runs three strategies in order to find the originating prospect:

Strategy 1 — exact member ID match. The cleanest path. If we already have a member ID stored on a prospect row in a running campaign, and the webhook's member ID matches, we bridge them directly. Fires for the majority of accepts.
Strategy 2 — public-handle match. If we stored a public LinkedIn URL (e.g. linkedin.com/in/someone) on the prospect row but never resolved it to a member ID before the invite went out, we re-run the URL-to-member-ID resolver against the webhook and check for a match. Fires when a prospect's URL was added pre-resolution.
Strategy 3 — name + workspace + recency match (relaxed). If both ID-based strategies miss, we fall back to a name-based match scoped to the same workspace and a recency window (the prospect must have been invited within the last 30 days from the same LinkedIn account). This is the strategy with the most uncertainty — we apply strict guards (only fires when there is exactly ONE candidate matching the name, never on ambiguous matches) to prevent accidentally bridging the wrong prospect.

If all three strategies miss, we record a bridge miss trace row. The trace includes which strategies were attempted, how many candidates each strategy found, and why each strategy rejected its candidates (e.g. "Strategy 3 found 2 candidates, rejected as ambiguous").

The four most common causes of a bridge miss

Most bridge misses fall into one of four categories. The trace data tells us which:

The workspace has no running campaigns. If a customer has archived or paused all their LinkedIn campaigns, then a late-arriving accept webhook for a prospect they invited weeks ago has nowhere to go. We classify this as a separate no_running_campaign trace branch (see Why some accept webhooks are not actioned), not a bridge miss — but it shows up in the same dashboard tile and customers sometimes call it a bridge miss too. The fix: re-engage by exporting the orphan accepts and creating a new campaign.
The invite was sent from a different LinkedIn account than the webhook is targeting. If you have multiple LinkedIn accounts in the same workspace and a prospect was invited from account A but accepted while account A was disconnected and account B was active, the webhook may be delivered to account B's listener. The matcher's strict guards prevent cross-account bridging in this case (we'd risk attributing the wrong send credit), so the row is recorded as a bridge miss. The recurring late-accept heal sweep handles these post-hoc when both accounts are connected.
The prospect's LinkedIn URL or name changed since the invite was sent. If a prospect updates their public LinkedIn handle or display name between when you sent the invite and when they accepted, our Strategy 3 name-match falls through. Strategy 1 (member ID) saves us if we'd already resolved their member ID before sending; Strategy 2 (URL re-resolution) saves us in some other cases. When both fail, the row is a bridge miss. Less common but a real category.
The webhook arrived during a deploy or worker restart. Less than 0.1% of cases — webhook delivery during a 30-second deploy window can race with the matcher's database lookups. We have a recurring heal that catches these, but they show up briefly in the trace.

What we do about bridge misses

Three layers of mitigation:

Trace observability. Every bridge-miss row carries diagnostic data describing which strategies were tried and how many candidates each found. Engineering uses this to iterate on the matcher (e.g. relaxing Strategy 3's name-match to allow common typo variations, while keeping the ambiguity guard).
Recurring late-accept heal sweep. Every 6 hours we sweep for prospects whose LinkedIn-side state shows them as "accepted" but whose linkedin_accepted_at column was never written by the matcher. For each, we stamp late_accept_observed_at on a separate column (so workflow forward-movers don't re-arm — see What is a "late accept"?) and surface the row on the dashboard's Late Accepts tile with a manual "Send follow-up" CTA.
Manual fix-up CTAs. The Late Accepts dashboard tile shows you every late-arriving accept with a one-click follow-up action. The action uses one slot from your daily message-cap bucket (per the cap-split documentation), respects per-account ramps and cooldowns, and goes through the same canonical pipeline as a normal send.

Bridge miss vs late accept vs orphan webhook

Three closely-related concepts that all show up on the dashboard's Webhook Events tile. The differences matter:

Bridge miss (covered on this page): workspace HAS running campaigns; matcher tried three strategies and couldn't tie the webhook to a specific prospect. Treated as a potential bug to iterate on.
Late accept: workspace HAS a running campaign and the matcher DID find the prospect, but the prospect's workflow has already moved past wait_accept (timed out, condition_skipped, completed, stopped). Recorded on late_accept_observed_at and surfaced with a manual-followup CTA. By-design behaviour. See What is a "late accept"?.
Orphan webhook (no_running_campaign): workspace has ZERO running LinkedIn campaigns (everything archived/completed/paused). Recorded informationally; no action taken. By-design behaviour. See Why some accept webhooks are not actioned.

The dashboard distinguishes all three so you can quickly tell which category a webhook event landed in.

How to spot a bridge-miss problem in your dashboard

Most bridge misses are recovered automatically by the recurring heal sweeps, so a single-digit count of bridge misses on your dashboard is normal background noise. Concerning patterns to watch for:

Bridge-miss count rising sharply day-over-day (specifically: >50 in a 24h window without a corresponding spike in invites sent).
Bridge misses concentrated on a single LinkedIn account in your workspace (suggests an account-state issue — possibly disconnected mid-day).
Late Accepts tile starting to fill with prospects from your most recent campaigns (suggests the bridge matcher is missing in real-time and the heal sweep is the only path catching them).

If you see any of these patterns, reply to your last support thread with a screenshot of the dashboard's Webhook Events tile and we'll pull the trace data for the affected webhook IDs to diagnose.

Account-safety note

Account safety always wins: the bridge matcher is read-only at the LinkedIn boundary. It never fires LinkedIn API calls during webhook handling — every match is a pure database lookup against the prospect's stored identifiers. The trace observability rows that record bridge-miss events are pure database writes; no LinkedIn-side action is taken on a bridge miss. The recurring heal sweep also makes zero new LinkedIn API calls; it stamps internal columns and enqueues follow-ups via the existing send pipeline (which respects all caps, ramps, cooldowns, and sending-window guards). At no point does a bridge miss put your LinkedIn account at risk.

What is a "late accept"? — covers the by-design case where the matcher DID find the prospect but the workflow has already moved on.
Why some accept webhooks are not actioned — covers the by-design case where the workspace has zero running LinkedIn campaigns (orphan webhooks).
Troubleshooting: missed accept — covers the in-time accept case (workflow still active when the webhook arrives).
Why was my prospect skipped — no LinkedIn URL? — covers the related case where a prospect URL couldn't be resolved at enrollment time.
How WarmySender handles load — explains the recurring heal sweeps that catch bridge misses post-hoc.