The LinkedIn Connection Request Limit: 382 Refusals We Named After the Wrong Thing

Across 4,355 invitation attempts from 20 LinkedIn seats, 382 came back refused. The refusal text says the account hit a temporary limit and names no recipient. We named that error already_invited_recently. Our own data says the name is wrong: all 382 were different people, and none had been successfully invited by that seat before. The condition sits on the sending account, not on the recipient.

LinkedIn's User Agreement prohibits automated access to the platform. The numbers below describe what accounts connected to our product received on the dates shown — they are not permission, not a safety guarantee, and not advice to breach that agreement. Your account, your risk.

What we read, exactly

One table, one filter. Kairon's production Postgres, table channel_action, rows where type = 'invite.send'. Nothing else was read. The rows come from 20 seats across 14 organizations connected to the product, all of them running B2B outbound in Latin America, sending the invitations they were going to send anyway. No account was driven to produce this data.

The refused seats are not ours. They sit across payments infrastructure, marketing services, talent, and an independent consultant selling to consumer brands. We describe them by sector and name no company.

Say the unflattering part plainly: Kairon's own seats made 792 attempts here, 648 of them landed, and not one row from our organization carries a cannot_resend_yet refusal — counted over the same table and window as everything else here. This finding is not about our own sending. We are not the ones who hit the wall, and there is no version of this piece built on accounts we control.

The reason is not restraint on LinkedIn's part. Our own seats account for 143 of the 213 attempts our software stopped before they went out — two thirds of every self-refusal in the table below came from us, and 18% of our own attempts, against 6% for the next organization. Do not read that as the reason we have nothing to report. Our ceiling was 39, above the 35 default, and the seat that drew the most refusals in this study landed fewer invitations per day than ours did.

First row 2026-06-18 19:27:37 UTC, last row 2026-08-16 02:52:34 UTC. First read at 2026-08-16 14:51 UTC and re-derived independently the same day by a second pass that checked these numbers against the database rather than against our notes. Aggregate only: no recipient identifiers, no message bodies, no organization names left the query.

That read licenses counts and per-seat-day aggregates of invitation attempts and their outcomes. It licenses nothing about accept rates, reply rates, or message sends.

What came back

Status	Rows
ok	3,735
failed	407
limited	213

The 213 never reached LinkedIn. limited is our own ceiling, not LinkedIn's: Kairon records the row and refuses the call before the invitation goes out. The ceiling defaults to 35 invitations a day and is set per seat, but the counter it checks runs per organization and owner over that owner's calendar day — so two seats under one owner share one allowance. The three ceilings that actually fired here were 39 (143 rows), 35 (45) and 40 (25). Everything after this paragraph is about the 407 that LinkedIn's side answered.

Provider error type	Rows
errors/cannot_resend_yet	382
errors/cannot_invite_attendee	15
errors/already_invited_recently	10

Whose words these are

The 382 are stored verbatim, in two variants that differ only in the top-level "code" key — our own mapped code, written alongside the raw provider object. 184 rows carry "code": null, from before the mapping landed. 198 carry "code": "already_invited_recently", from after. This is one of those 198, whole — with our API vendor's name replaced by [provider], and nothing else changed:

{
  "code": "already_invited_recently",
  "status": 422,
  "message": "[provider] 422: Cannot resend yet — You have reached a temporary provider limit. Please try again later.",
  "provider": {
    "type": "errors/cannot_resend_yet",
    "title": "Cannot resend yet",
    "detail": "You have reached a temporary provider limit. Please try again later.",
    "status": 422
  },
  "retryable": false
}

Read the labels carefully, because both of them are somebody else's.

errors/cannot_resend_yet is our API vendor's label. That vendor is the intermediary we send LinkedIn actions through, and we do not name it here. It is the vendor's description of what it received, not a phrase LinkedIn said to us. We did not observe LinkedIn's own response, and we cannot see LinkedIn's internal counter.

already_invited_recently is Kairon's own internal error code, and we map errors/cannot_resend_yet onto it deliberately — a decision that landed on 2026-07-04. That is why 184 of the 382 rows carry a null error code, dated 2026-06-29 to 2026-07-05, and 198 carry already_invited_recently, dated 2026-07-09 to 2026-08-12. The commit landed on 2026-07-04, a day before the last null row — the boundary is the deploy, which we did not pin to the hour. If you see that string in our product, it is our word for what the vendor told us. It is not a quote from LinkedIn.

And read the provider text once more: "Cannot resend yet — You have reached a temporary provider limit." It names no recipient at all. It is a statement about a limit the account reached. The idea that the refusal means "you already invited this person recently" exists only in our own code name for it. We took an account-level limit and gave it a per-recipient name. The next section is our own data saying that name is wrong.

The 10 rows in the table above with a provider type of errors/already_invited_recently are a different thing again: that is the vendor's own separate label, on 10 rows, and it is not part of the 382.

Every refusal was a different person

cannot_resend_yet refusals	382
Distinct recipients among them	382
Refusals where that seat had successfully invited that person before the refusal	0
Refusals where that seat successfully invited that person after the refusal	4

382 refusals, 382 distinct recipients. Not one person was refused twice. In 382 of the 382, the seat had never successfully sent an invitation to that person before being refused.

Four later successes do exist, and they cut the other way. All four are on one seat, 019f6b7a, landing two to three weeks after its refusals. The same seat, the same people, an invitation that goes through. That is the state clearing, not a per-recipient block.

already_invited_recently is our name, and it describes a per-recipient block. A per-recipient block repeats on the same person. This one never did, and the provider text it maps from never mentioned a person. The state that produced it lives on the sending account.

One caveat on that check, and it matters: we counted successful invite.send rows from the same seat to the same recipient, dated before the refusal, inside this window, in our own ledger. We did not read cancellations, and we cannot see invitations sent from that account outside Kairon. LinkedIn's own withdraw an invitation page says withdrawing blocks you from re-inviting the same person for up to three weeks — a real mechanism that would explain a refusal on a specific recipient. It cannot explain 382 people the seat had never reached.

It did not track volume

Here is every seat-day in the window, bucketed by how many invitations that seat landed that day, against how many refusals it drew.

Invitations sent that seat-day	Seat-days	Refusals
0	10	202
1–10	81	88
11–20	50	34
21–30	70	58
31+	23	0

Read the two ends. 23 seat-days sent 31 or more invitations and drew zero refusals. 10 seat-days sent zero invitations and drew 202 — more than half of all the refusals in the study. On 8 of those 10, every single attempt the seat made came back refused; the other two made one attempt each and it failed for a different reason. That inverts the shape of the advice we went looking for and could not source: a daily connection request limit where the refusal is the punishment for the volume.

Now the part that matters more than the finding: 23 seat-days is not permission to send 31 a day, and the reason is that the bucket is censored by our own cap. The highest invite.send ceiling on any of the 20 seats is 40, so the bucket runs from 32 to 56 and stops. We cannot observe what 80 a day does, because our product would not send 80. Absence of refusals up there is absence of evidence that our own ceiling manufactured. We are reporting what the buckets contained. We are not giving you a number.

For scale on the rest of the window: the mean across 234 active seat-days was 16.0, where "active" means a seat-day on which the seat attempted at least one invitation. The top of the range, 56, sits above every ceiling we set, and that is a bucketing artefact rather than a seat beating the cap: the counter runs over the owner's calendar day while this table groups by UTC date, so one owner-day can straddle two UTC days.

It came in streaks, per seat

Five of the 20 seats ever saw a refusal. When one did, it usually saw them for days. Seat 019ef087, ids truncated to eight characters and identifying nobody:

Day	Sent	Refused
2026-06-29	26	9
2026-06-30	4	30
2026-07-01	0	35
2026-07-02	0	35
2026-07-03	0	35
2026-07-04	0	25
2026-07-05	0	9

Seven consecutive days. Volume collapses from 26 to 4 to nothing, and the refusals rise anyway. For five straight days that seat landed no invitations at all and every attempt came back refused. Then it stopped.

Two of the other four show the same shape. 019f38d6 ran a nine-day scatter from 2026-07-04 to 2026-07-26, including 2026-07-10 where it sent 0 and drew 50. 019f6b7a drew 26, 11 and 2 on 2026-07-21, 22 and 23, sending 6 then 0 then 0. The rows group by seat, not by date. Whatever this is, it is a per-account state with a duration.

What LinkedIn publishes about this

Its invitation limit page says that if you reach the limit, "your account may be temporarily restricted from sending invitations. This restriction typically lasts one week," and adds that LinkedIn Support cannot disclose the type or reason for a restriction, even to the account holder. It does name one number — "Basic and free LinkedIn members can include a personalized message to five connection requests per month" — but that caps the notes, on free accounts, not how many invitations you may send. The commercial use limit page covers searches and profile views and states LinkedIn cannot display how many you have left. The one hard figure we found is a 30,000 first-degree connection ceiling on the network size limit page.

We found no LinkedIn help page that names a daily or weekly invitation number, reading those four pages on 2026-08-16. That is what our reading covered, not a statement about what exists.

The one-week duration on that page is the closest published thing to the streaks above, and the durations we measured do not contradict it. We are pointing at the resemblance, not claiming it is the same mechanism — we never saw LinkedIn's side.

What this data cannot say

• An API vendor sits between us and LinkedIn. errors/cannot_resend_yet is that vendor's label for what it received. We did not observe LinkedIn's own response, so nothing here describes LinkedIn's internal counter.
• None of this is a controlled experiment. Different seats, different audiences, different campaigns, different account ages and histories. Every seat self-selected into whatever volume its operator chose. Nobody held anything constant.
• The 31+ bucket is censored by our own cap. It is 23 seat-days, and it stops where our ceilings stop: the highest on any of the 20 seats is 40, and the one 56 in there is a UTC-date artefact, not a seat that beat the cap. Absence of a refusal above 30 a day is absence of evidence that our own product manufactured. Nothing here observes 60, or 100.
• Pace was never measured. Every figure here is a per-day count. Thirty invitations in ten minutes and thirty across eight hours are the same number in these tables, and we did not vary the spacing to find out whether it matters.
• Five seats is five. The pattern is what 20 seats did over two months.
• The sectors are our own description, written from what each account sells. There is no industry field in the data; nothing was looked up, and no company is named.
• 213 of the 4,355 attempts are our own product stopping itself, at ceilings of 39, 35 and 40, before the invitation reached LinkedIn. Those rows say nothing about LinkedIn's behaviour. They are in the totals because leaving them out would make the outcome table not add up.

What to do with this

Check whether your own tooling can answer the question we just answered: when an invitation fails, does it store the provider's raw payload, or does it store your vendor's summary of it? Ours stores both, which is the only reason the distinction between errors/cannot_resend_yet and already_invited_recently was recoverable two months later. If your stack keeps a status code and drops the body, you cannot tell a per-recipient block from a per-account state, and you will spend a week tuning volume against something volume did not move here.

If the question behind your search was which subscription tier buys you room, we measured that separately and the answer was no: Premium and Sales Navigator change credits and search reach. What restricted the account in that study was pace — a different mechanism, a different read, on different accounts. This read says nothing about pace either way. Every bucket above counts invitations per day, and thirty invitations sent in ten minutes and thirty spread across eight hours land in the same row. We did not vary the spacing, so do not read "volume did not predict these refusals" as "spacing does not matter". And if you want the outcome side rather than the refusal side, we read 9,592 of our own agent-run sequences to see where outbound actually ends, reply rate included — then narrowed to our own seats and measured what 923 sends actually got back, including how the rate moves between campaigns inside one account.