Sales Navigator URL imports and acceptance tracking

What this page covers

If you have imported prospects into a WarmySender LinkedIn campaign using Sales Navigator URLs (the kind that look like linkedin.com/sales/lead/ACw…), and you have wondered why some accept signals took a while to flow through to your dashboard pre-May 7, 2026, this page explains the underlying mechanics and the fix we shipped on May 7. 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:

How Sales Navigator URLs work

LinkedIn has two main URL formats for a profile:

When you export a prospect list from Sales Navigator, the URLs use the second format. Our importer accepts both — but the difference matters when a webhook arrives, because LinkedIn's webhook payload uses the canonical (standard-URL) format, not the Sales Nav format.

What the "bridge" is and why it matters

When a prospect accepts your invite, our LinkedIn integration delivers an invitation.accepted webhook to our server. The webhook payload contains the prospect's LinkedIn member ID and a few other identifiers. Our matcher then has to figure out: which prospect in your campaign is this webhook about? That matching process is what we call the bridge.

The bridge runs three strategies in order — exact member ID match, public-handle match (this is the new fourth condition introduced in V16), and a relaxed name + workspace + recency match. If all three miss, we record a "bridge miss" trace for engineering to look at. For a deeper read on the matcher itself, see What is a bridge miss and when does it happen?.

The pre-V16 gap (and why it bit Sales Nav imports)

Before May 7, 2026, our matcher had two anchors for a Sales Nav prospect at webhook time:

  1. The Sales Nav URL we stored at import (/sales/lead/<URN>).
  2. The LinkedIn member ID — but only if we had already resolved it through our LinkedIn integration, which only happens when an invite is sent (and even then, only for prospects whose URL could be resolved at that moment).

The webhook payload, on the other hand, carries the canonical member ID and the standard-URL public slug — neither of which lined up cleanly against a stored Sales Nav /sales/lead/<URN> URL. If we had the member ID stored on the prospect row, Strategy 1 caught it. If we did not, the bridge had no shared anchor, the matcher missed, and the row landed on the bridge-miss trace branch.

Production data showed this hitting around 39% of accept webhooks in a rolling 24-hour window — the kind of rate that's clearly a structural mismatch, not a long-tail edge case. So we shipped a fix.

What changed in V16 (May 7, 2026)

Three changes, all evergreen:

  1. Schema: a new column linkedin_public_handle on the prospect row, indexed for fast lookup.
  2. Invite-send capture: when we resolve a prospect's URL to a member ID (this happens at the moment we are about to send the invite — never speculatively), we now capture both the member ID and the public-handle slug. Both go onto the prospect row in a single atomic update. From this point on, the prospect has a stable webhook-bridge anchor regardless of what URL format the original import used.
  3. Webhook bridge — fourth match condition: when an accept webhook arrives, our matcher now has a fourth strategy condition that compares the webhook's public-handle slug against the linkedin_public_handle we stored at invite-send time. For Sales Nav imports, this is the path that catches the accept.

None of this changes the campaign workflow itself. Your steps run exactly as you authored them. The fix is purely about connecting the webhook to the right prospect row — it doesn't bypass any cap, ramp, cooldown, or sending-window guard. Account safety wins.

The one-shot retroactive backfill

The fix above only helps prospects invited after the May 7 deploy. For Sales Nav prospects invited before that, we ran a one-shot backfill that:

Names that matched multiple connections (e.g. two "John Smith" relations) we tagged "ambiguous" and did not write — being conservative is the right call. Customers with ambiguous matches can still benefit from the fix going forward, since any new invite will capture the slug at send time.

Account safety

Two invariants we hold, always:

If you have asked yourself "why does this take 20+ minutes when it could be done in 30 seconds?" — this is the answer. Speed is a tradeoff against account safety, and we always pick safety. A faster backfill that gets one customer's account flagged is a far worse outcome than a slow backfill that takes a coffee break to run.

How to tell if this affected your campaigns

If you imported prospects from a Sales Navigator export between roughly mid-March and May 7, 2026, and saw a higher-than-expected rate of "Invited but never marked Connected" prospects on your campaign dashboard, the V16 fix probably explains a chunk of it. The recurring late-accept heal sweep we run every 6 hours catches additional cases (it stamps a separate late_accept_observed_at sentinel — see What is a late accept?), and the Late Accepts dashboard tile shows you any prospects in that bucket with a one-click "Send follow-up" CTA.

For prospects imported with regular /in/<handle> URLs, the bridge was already finding them in the URL-normalization condition before V16 — those imports were not affected.

What to do now

Three options, depending on how thorough you want to be:

  1. Do nothing. The retroactive backfill ran on May 7, the live fix is in place, and the recurring heal sweep continues to catch edge cases. Your dashboard will reflect accurate accept counts going forward.
  2. Spot-check the Late Accepts tile. Open your campaign dashboard, look at the Late Accepts tile, and review the prospects there. Each row has a "Send follow-up" CTA that uses one slot from your daily message-cap bucket — useful for prospects you actively want to engage. The CTA respects all caps and ramps.
  3. Re-import. If you would prefer to start clean, re-export your Sales Nav list with standard /in/<handle> URLs (Sales Navigator has a "Copy public profile URL" option per lead) and re-import. New imports will capture the slug at the moment the invite is sent and never hit this gap.

If something doesn't look right after the fix, email hello@warmysender.com with the prospect URL and campaign name — we will check the specific row from our side.

Frequently asked questions

Does this fix change how my campaign sends?

No. The fix is purely about how we identify the prospect when an accept webhook arrives. Your campaign steps, sending windows, daily caps, ramp settings, and cooldowns are all unchanged. The only thing that changes is whether we successfully bridge the webhook to the right prospect row.

Will my Sales Nav campaigns send any faster after V16?

Send pace itself does not change — caps and ramps still apply. What changes is the time-to-status: more accepts now flip your prospects to Connected on the same day they actually accepted, instead of taking until the next 6-hour heal sweep (or longer) to surface.

What if the backfill couldn't disambiguate two prospects with the same name?

Those rows we tagged "ambiguous" and did not write. They will pick up the canonical slug naturally on the next invite send (e.g. if you add them to a new campaign), or you can edit the prospect's URL to a regular /in/<handle> URL and the next campaign tick will resolve and store the slug.

Is there any risk to my LinkedIn account from the backfill?

No. The backfill called the relations-list endpoint at one call per account per 60 seconds, hard-capped at 23 accounts per run. That is far below any threshold LinkedIn would consider abnormal for an individual account. Your account safety profile is unchanged.

What happened to prospects whose accept webhook was delivered before we shipped the fix?

For Sales Nav prospects, those accepts were largely the source of the 39% bridge-miss rate we observed. The retroactive backfill closes the loop on those prospects whose name matched a current relation. Anything not bridgeable that way (account disconnected since, prospect removed connection, etc.) will not be retroactively recovered, but the recurring heal sweep continues to catch any future late-arriving signals from those same prospects.

Will I see a sudden spike in my "accepted" count after the fix?

You may see a small step-up on May 7-8 as the backfill writes catch up. After that, your accept counter reflects real-time activity again. No double-counting — the backfill skips rows that were already stamped via any other path.

What if I never use Sales Navigator URLs?

Then this fix changes nothing for your campaigns. Standard /in/<handle> URLs were always covered by the URL-normalization match condition in Strategy 2.

Where can I read more about the matcher in general?

See What is a bridge miss? for the matcher's three-strategy design, and What is a late accept? for the recurring heal sweep that catches any edge cases the live matcher misses. The If you suspect a missed accept guide walks through the customer-facing self-service steps.

Still have questions? Email hello@warmysender.com with your campaign name and a prospect URL — we will check the specific row from our side.