> ## Documentation Index
> Fetch the complete documentation index at: https://docs.edges.run/llms.txt
> Use this file to discover all available pages before exploring further.

# How Limits Work

> The five limit systems behind every Edges call, who enforces each one, and which of them you actually have to plan around.

Five separate systems can stop a call. They are not variations of one rule — they differ in **who enforces them**, **what they are scoped to**, and **what you can do about them**. Knowing which one spoke is what turns a `429` into a decision.

## The five systems

| System                                                   | Enforced by | Scoped to                          | Your lever                               |
| -------------------------------------------------------- | ----------- | ---------------------------------- | ---------------------------------------- |
| [Plan rate limits](/v1/runs/rate-limits)                 | Edges       | Your workspace, per endpoint       | Slow down, or move up a plan             |
| [Concurrency](/v1/runs/rate-limits#concurrent-execution) | Edges       | Your workspace, async runs         | Plan tier; how you shape runs            |
| [Action limits](/v1/linkedin/limits)                     | Edges       | One identity, one action type      | Add identities, or wait for the window   |
| Identity throughput                                      | Edges       | One identity, all actions together | Add identities                           |
| LinkedIn's own limits                                    | LinkedIn    | The account itself                 | Account type, and behaving like a person |

<Note>
  Four of the five are ours. We set them **below** what LinkedIn tolerates, which is the point — an account stopped by an Edges limit is an account that did not get restricted by LinkedIn.
</Note>

### Plan rate limits

How many API requests your workspace may make per minute, counted separately for each family of endpoints — running actions, managing identities, reading workspace data, polling runs. This is about your integration's traffic, not about LinkedIn.

### Concurrency

How many async runs Edges processes at once, and how each run is split into batches. This shapes **how fast a large job finishes**, not whether it is allowed. Submit as much as you like: extra runs queue and start as slots free up.

### Action limits

The quotas most people mean by "limits". Each LinkedIn action type has its own allowance, tracked **per identity**, on rolling windows — per minute, and then longer windows up to 24 hours. Hitting one action's limit leaves every other action on that identity untouched.

<Tip>
  Rolling, not calendar: a 24-hour window frees up gradually through the day as the calls that filled it age out, rather than resetting at midnight.
</Tip>

A newly connected identity does not start at full allowance — see [Identity Ramp-Up](/v1/limits/identity-ramp-up).

### Identity throughput

A ceiling on **everything one identity does**, whatever the mix of actions. Where action limits ask "how many connection requests today?", this asks "how much total activity in the last minute?". You will rarely meet it first; when you do, the answer is more identities rather than more patience.

### LinkedIn's own limits

Everything above is ours. LinkedIn also enforces its own caps and protections on the account, and those are not published, not stable, and not something we can raise. We detect them and hand them back with a distinct label so you can tell them apart from ours — see [Which limit was hit](/v1/error-reference#which-limit-was-hit).

## Which of these you have to plan around

This is the practical question, and the answer depends on how you supply accounts.

<Columns cols={2}>
  <Card title="Bring your own accounts" icon="user">
    You own the identities, so **action limits are your ceiling**. Capacity grows by adding identities, not by pushing one harder. Plan rate limits are unlikely to be what stops you.
  </Card>

  <Card title="Managed" icon="users">
    You don't own the identities, so **your plan's rate limits are your ceiling**. Keeping enough capacity available is our job — you are not planning against per-account caps at all.
  </Card>
</Columns>

<Info>
  The quotas themselves are identical in both cases. What changes is who absorbs them.
</Info>

## Credits are not a limit

Credits are what a run **costs**; limits are what a run is **allowed** to do. Exhausting credits and hitting a limit are different failures with different fixes. See [Credit costs](/v1/api/credit-costs) for pricing.

## When a call is refused

Every limit rejection names the window it came from, so you can wait the right amount of time instead of backing off blindly.

<CardGroup cols={2}>
  <Card title="Which limit was hit" icon="circle-exclamation" href="/v1/error-reference#which-limit-was-hit">
    Every label, what it means, and how long to wait.
  </Card>

  <Card title="Recover a blocked run" icon="rotate-right" href="/v1/runs/recover-blocked-run">
    Resuming work that stopped part-way.
  </Card>
</CardGroup>

## Related

<CardGroup cols={3}>
  <Card title="Action limits" icon="shield" href="/v1/linkedin/limits">
    Every quota, by account level, and which actions consume it.
  </Card>

  <Card title="Plan rate limits" icon="gauge-high" href="/v1/runs/rate-limits">
    What your API key may do per minute.
  </Card>

  <Card title="Identity Ramp-Up" icon="chart-line" href="/v1/limits/identity-ramp-up">
    Why a new identity stops earlier than the table says.
  </Card>
</CardGroup>
