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 runs your outreach on autopilot with AI agents, across Cold Email, Email Warmup, LinkedIn, Instagram and Multichannel sequences — plus real-time email verification. This page is part of the LinkedIn channel.

The short version:

• What changed: we now capture the canonical LinkedIn slug (the /in/<handle> portion) for every Sales Nav prospect at the moment we send the invite — not just the encoded Sales Nav lead identifier. The slug is what LinkedIn uses inside the accept-webhook payload, so we now have a stable anchor on both ends.
• Why it matters: Sales Nav URLs encode a different identifier than the canonical LinkedIn member ID that the webhook delivers. Pre-fix, our webhook bridge had no shared anchor for Sales Nav prospects whose member ID had not been resolved at enrollment time. The fix gives the bridge a fourth match condition that closes that gap.
• Account safety: the live webhook bridge is purely database-driven — it makes zero LinkedIn API calls during webhook handling. The one-time retroactive backfill we ran for historical Sales Nav prospects is rate-capped at one call per account per minute, with a hard cap of 23 accounts per run. Far below the threshold that LinkedIn would consider abnormal for any single account.

What you need to import a Sales Navigator list

Importing profiles from a Sales Navigator list URL (the kind that looks like linkedin.com/sales/lists/people/…) needs the connected LinkedIn account to be carrying Sales Navigator access, and it has to be the same account that owns the list. Sales Navigator is a paid LinkedIn upgrade, so a standard or free LinkedIn account can't open those lists — pick a LinkedIn account that's on Sales Navigator before you import.

Have Sales Navigator but the list still won't import? After you reconnect a LinkedIn account, it can come back without Sales Navigator access even though your subscription is still active — and it may show its plan as Premium. When that happens the list can't open yet. The one-click fix is the Re-check Sales Navigator access button that appears on the import screen next to the account you're importing with: pick that account, click it to restore Sales Navigator access, and start the import again. If the re-check can't find it, reconnect the account while Sales Navigator is open in the same browser, then try the import again. Full walkthrough: Why won't my Sales Navigator list import?

If you're on a standard LinkedIn account, you can still build audiences three other ways — and all of these work on any connected account:

• Paste a regular LinkedIn search URL — the kind that looks like linkedin.com/search/results/people/…. Run a search on LinkedIn, copy the URL from your browser, and import it.
• Paste individual profile URLs — drop in one or more linkedin.com/in/<handle> links to add specific people.
• Upload a CSV — bring your own list of profiles from a spreadsheet.

WarmySender runs your outreach on autopilot with AI agents, across Cold Email, Email Warmup, LinkedIn, Instagram and Multichannel sequences, plus real-time email verification — and audience building applies to the LinkedIn and Multichannel channels.

You imported your list — now put it in a campaign

This is the step people miss most often, and it is the difference between "my list imported fine" and "my list is actually reaching anyone". Importing builds an audience and adds those people to your prospects. Nothing is sent until that audience is part of a campaign — a campaign is what decides who gets contacted, with which message, in what order, and at what pace.

The fastest way (about 10 seconds)

1. Open LinkedIn › Audiences and click the audience you just imported.
2. Click Import to Prospects if you have not already. A card appears saying how many people were imported.
3. On that card, click Add to a campaign, pick the campaign you want them in, and confirm.

That is it. Everyone from the audience who is already in your prospects joins that campaign, and anyone you import into the same audience later joins it automatically — you do not have to repeat this each time you top the list up.

How to tell whether an audience is actually sending

Every audience card in LinkedIn › Audiences now carries one of two labels:

• In N campaigns — this audience is part of N campaigns. People in it are being contacted (at whatever pace those campaigns run).
• Not sending yet — add to a campaign — the audience has people in it but belongs to no campaign, so nobody in it is being contacted. Click the label to fix it on the spot.

If you have re-imported a list because the first attempt looked wrong, this is the label to check. A fresh, correct audience that is not in any campaign will happily sit there doing nothing while an older campaign carries on with the older list.

Adding to a campaign that is already running

You can add an audience to a campaign that is already sending. It does not restart the campaign, it does not change your sequence, and it does not change your daily pace or your sending hours. New people simply start at step one and go out at your campaign's normal rate.

Nobody is contacted twice. Anyone already in that campaign is recognised and skipped — including someone who is in there under an earlier import, so a re-imported list that overlaps the original is safe to add.

If the campaign is paused or still a draft, the people are added and simply wait. They start when you start the campaign.

"I added it and still nothing is going out"

• Some of the audience is not imported yet. Only people who are in your prospects can be added to a campaign. Open the audience and click Import to Prospects — the confirmation tells you how many are still waiting.
• The campaign is not started. Open the campaign and check its status — a draft or paused campaign holds everyone until you start it.
• It is early in your pace. New LinkedIn accounts start slow on purpose and every account has a daily ceiling, so a 100-person audience goes out over days, not minutes. See Why your new LinkedIn account starts slow.
• The campaign screen tells you. If people from an audience the campaign draws from are not in it yet, the campaign page shows a note with the exact number and a one-click button to add them.

How Sales Navigator URLs work

LinkedIn has two main URL formats for a profile:

• Standard URL — linkedin.com/in/<handle>. The <handle> is the public slug LinkedIn assigned (or that the user customized). This is what the LinkedIn platform itself uses inside its accept-webhook payloads.
• Sales Navigator URL — linkedin.com/sales/lead/<URN>. The <URN> is an opaque, base64-style encoded identifier. It is unique to a profile, but it is not the same value as the canonical member ID inside webhook payloads.

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:

• Identified Sales Nav prospects whose linkedin_public_handle was empty and whose invite had already gone out.
• For each LinkedIn account with at least one such prospect, called one relations-list endpoint to fetch the current connections.
• Matched stuck prospects against the relations list by full name. Where exactly one relation matched, we wrote the slug + member ID onto the prospect row.
• Slept 60 seconds before moving to the next account, with a hard cap of 23 accounts per run. That keeps us provably below LinkedIn's "this looks abnormal" threshold for any individual account.

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:

• Zero LinkedIn API calls in critical webhook paths. The new fourth match condition is a database lookup against the slug column we now persist at invite-send time. A webhook arriving for a Sales Nav prospect resolves entirely via stored data — we never call out to LinkedIn during webhook handling. This matters because webhook traffic can spike, and any per-webhook LinkedIn call would risk tripping LinkedIn's "automated activity" filter.
• The retroactive backfill respects per-account spacing. 1 call per account per 60 seconds, hard-capped at 23 accounts per run. The whole run takes ~23 minutes wall-clock — slow on purpose. LinkedIn-side restrictions on a real account are unrecoverable, so we err on the slow side.

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 [email protected] 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.

I imported my list and nothing is being sent — what did I miss?

Almost always the audience is not in a campaign yet. Importing creates an audience and adds those people to your prospects; a campaign is what actually contacts them. Open LinkedIn › Audiences — if the audience says "Not sending yet — add to a campaign", click it, pick your campaign, confirm, and you are done. Full walkthrough above: You imported your list — now put it in a campaign.

If I add my re-imported list to a campaign that is already running, will anyone get contacted twice?

No. Anyone already in that campaign is recognised and skipped, including people who are in there from an earlier import of the same list. Only genuinely new people are added, and they start at step one at your campaign's normal pace. Adding people never restarts the campaign and never speeds it up.

Do I have to repeat this every time I add more people to the audience?

No. Once an audience is part of a campaign, anyone you import into that audience afterwards joins the campaign automatically. You only need to do it once per audience per campaign.

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.

Related guides

• What is a "bridge miss" and when does it happen? — three-strategy matcher overview
• What is a "late accept"? — the recurring heal sweep + Late Accepts dashboard tile
• Why was my prospect skipped (no LinkedIn URL)? — Sales Nav resolution failures and the Skipped panel
• If you suspect a missed LinkedIn accept — customer-facing self-service guide
• Why some accept webhooks are not actioned — orphan-webhook explainer
• Why does my late LinkedIn accept take time to message? — webhook-time auto-fire vs heal scheduler timing
• Full documentation — All 90+ guides
• Support — How to get in touch