Why was my LinkedIn InMail count corrected?

What this page is for

If your dashboard's InMail counter shrank between May 2 and May 3, 2026 — sometimes by a lot — this page explains exactly why, what we changed, and what happens next. Short version: every InMail counted in your dashboard now has cryptographic proof of delivery from LinkedIn (a returned chat reference). InMails that were silently dropped on the LinkedIn side without a chat reference no longer count. The number you see today is the truthful, verified-delivered count.

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.

What the May 2 fix changed

Before May 2, 2026, our LinkedIn engine counted an InMail as "sent" the moment the LinkedIn integration accepted the request. That sounds right — but it isn't a guarantee that LinkedIn actually delivered the InMail to the recipient's inbox. In a small but persistent fraction of cases, the request was accepted upstream and then silently dropped on the LinkedIn side, with no error visible to us at send time.

On May 2 we introduced a stricter invariant we call "chatId required for delivered". A successful, delivered InMail returns a chat reference (a chat_id) that links the message to a real LinkedIn conversation thread. If we don't get that reference back, we can't prove the InMail landed — so we no longer count it as sent.

The fix has two parts: (1) the engine now ONLY records an InMail row when the chat reference comes back, and (2) the dashboard refresher now excludes any historical InMail row that doesn't have a chat reference attached. The result is a dashboard counter that mirrors what actually went into recipients' LinkedIn inboxes — not what we hoped went in.

Why some historical counts dropped

Some accounts had a meaningful number of InMails recorded under the old (looser) rule that never had a chat reference attached — what we now call "phantom sends." When the May 2 fix shipped, the dashboard refresher started excluding those rows, and the displayed counter dropped accordingly.

The drop is real, in the sense that the InMails it represents never produced a confirmable LinkedIn conversation. The number you see now is the number of InMails we have proof of delivery for. If the gap between your old number and your new number is large, your account was disproportionately affected by the silent-drop bug. We're sorry — that's exactly the kind of upstream-integration regression that's hard to catch without the chatId invariant in place.

If you were affected, your connection-request acceptance rate is unchanged. The fix is scoped to InMail counters only — invite counts, accepts, replies, and connection-rate percentages are not touched, and were never wrong. Reply rate may now look healthier on your dashboard because the denominator (InMails sent) is more accurate; the same number of replies divided by a smaller, truthful sent-count gives a higher rate.

How "phantom send" detection works going forward

Three layers, each independent of the others, so a regression in any one layer is caught by the next.

Layer 1 — the engine refuses to record without proof

The send path now wraps the entire InMail lifecycle in a transaction: call LinkedIn, wait for the response, only insert a linkedin_events row if the response carries a chat reference. No chat reference means no row, no counter increment, no follow-up scheduled. The prospect goes back to the queue for the next safe attempt under your account's daily and weekly caps.

Layer 2 — the stats refresher excludes phantom-flagged rows

The dashboard counter is computed from a backing table called campaign_events that mirrors the engine's authoritative linkedin_events. Any row flagged as a phantom (no chat reference, recorded before the May 2 fix) is excluded from the count. The refresher runs on a regular cadence and the dashboard catches up within a few minutes.

Layer 3 — a new daily delivery health monitor

If a future regression silently re-introduced phantom sends, the layer-1 and layer-2 protections would still hold (the dashboard would reflect the truth), but the regression itself wouldn't be visible. So we added a third layer: a daily background job that scans the previous 7 days of InMail traffic per LinkedIn account and alerts us when either of two signals trips: (a) reply rate below 1% on a cohort of 50+ verified sends, or (b) more than 10% of sends recorded without a chat reference. The first signal is the most reliable — phantom sends can't generate replies, so reply rate cratering on a previously-healthy account is the cheapest detector we have. The second signal catches the bug at the source. Either trip raises an admin alert for our team to triage.

Common questions

Did I lose any prospects? Do I need to re-import or re-launch anything?

No. The phantom rows are metadata — flags on existing data, not deleted data. Your prospects, audiences, campaign sequences, and analytics are untouched. The fix only changes how we count and display InMails on the dashboard. If a prospect was recorded as having received a phantom InMail, they're now back in the eligible pool to receive a real, chat-reference-confirmed InMail on the next campaign tick (within your account's daily and weekly safety caps).

Why did my reply rate go up after the fix?

Because the denominator dropped. Reply rate = replies / InMails sent. The replies you got are real — they're confirmed conversations on LinkedIn. The "InMails sent" number was inflated by phantoms before the fix; now it reflects the verified sent count. Same number of replies, smaller denominator, higher rate. This is the truthful number and it's what we'll use for benchmarking going forward.

Will this affect my LinkedIn account safety?

No. Every change in the May 2 + May 3 deploy is database-only — zero new LinkedIn API calls, no LinkedIn rate-limit risk, no account flags. The engine respects per-account daily and weekly limits, sending windows, and timezone exactly as you configured them. Account safety always wins over throughput. A banned LinkedIn account is unrecoverable, so we never run shortcuts that risk a flag.

What should I do if my dashboard still looks wrong?

Hard-refresh once (the dashboard caches some derived counters for 60 seconds) and recheck. If the counter still doesn't match what you see in your LinkedIn inbox after a hard-refresh, contact support at hello@warmysender.com with the campaign name and a screenshot of the current value. We'll cross-check against the underlying linkedin_events rows for your account and confirm whether the counter is correct, the dashboard is stale, or there's a separate issue we should investigate. If you're seeing prospects parked in "pending template fix," that's a separate flow — see the template-fix auto-resume section for what to do.

Account safety

Zero new LinkedIn API calls. Every part of the May 2 + May 3 fix runs against our database — annotating phantom rows, updating the dashboard counter formula, and inserting alert rows. We don't re-poll LinkedIn to "verify" anything because re-polling at scale would risk tripping LinkedIn's automation detection and getting accounts restricted. The chatId invariant is checked once at send time (when we're already calling LinkedIn anyway) and then trusted as forensic proof from then on.

Per-account daily and weekly InMail caps, sending windows, and timezone scheduling are unchanged. The new daily delivery health monitor reads from the database only — it never calls LinkedIn. It writes a heartbeat row every run (whether or not it finds anything to alert on) so we can verify the cron is alive.

Still seeing something off? Email hello@warmysender.com with your campaign name and a screenshot — we'll dig into the specific account.