> ## 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.

# Rate Limits

> Learn about rate limits, quotas, and best practices for managing API usage with Edges.

Edges implements rate limits to ensure fair usage and optimal performance for all users.
Understanding these limits helps you design efficient automations and avoid interruptions.

## Overview

Rate limits are applied at multiple levels:

* **API Endpoints**: Per-minute limits on specific API calls
* **Daily Quotas**: Total daily usage limits based on your plan
* **Concurrent Execution**: Limits on parallel automated runs and batch processing

<Tip>Each plan includes a daily quota that represents your total usage allowance. This quota is consumed by all API calls across your workspace.</Tip>

## Plan Tiers

Your rate limits are determined by your plan tier, which is based on your monthly credit allocation. You can see your current tier in your [Workspace Settings](https://app.edges.run/settings/plans/credits).

| Plan Tier | Monthly Credits         | Description                             |
| --------- | ----------------------- | --------------------------------------- |
| Trial     | 1,000                   | Free trial with basic limits            |
| Bronze    | 2,500 - 10,000          | Starter plans for small teams           |
| Silver    | 10,001 - 100,000        | Growth plans for scaling teams          |
| Gold      | 100,001 - 500,000       | Business plans for expanding operations |
| Platinum  | 500,001 - 2,000,000     | Scale plans for high-volume operations  |
| Diamond   | 2,000,001 - 20,000,000  | Advanced plans for large organizations  |
| Titanium  | 20,000,001 - 50,000,000 | Enterprise plans for maximum scale      |

## API Rate Limits

### Real-time Actions

The most important rate limits apply to real-time action execution via `/v1/actions/{action-name}/run/live`.
These limits determine how many requests you can make per minute:

| Plan Tier          | Max Requests/Second | Max Requests/Minute |
| ------------------ | ------------------- | ------------------- |
| Trial              | 1                   | 60                  |
| Bronze             | 2                   | 120                 |
| Silver / Gold      | 10                  | 600                 |
| Platinum / Diamond | 20                  | 1,200               |
| Titanium           | 40                  | 1,200               |

<Note>For async actions, different concurrent execution limits apply (see [Concurrent Execution](#concurrent-execution) below).</Note>

#### Capacity Examples

Assuming an average request duration of 2-3 seconds:

| Plan Tier          | Estimated Daily Capacity | Example Use Case       |
| ------------------ | ------------------------ | ---------------------- |
| Trial              | \~86,400 requests/day    | Small-scale testing    |
| Bronze             | \~172,800 requests/day   | Individual prospecting |
| Silver / Gold      | \~864,000 requests/day   | Team sales operations  |
| Platinum / Diamond | \~1,728,000 requests/day | Large-scale enrichment |
| Titanium           | \~3,456,000 requests/day | Enterprise automation  |

**Example**: With a Silver or Gold plan (600 requests/minute), you can:

* Enrich \~864,000 LinkedIn profiles per day
* Process \~36,000 profiles per hour
* Handle \~600 concurrent enrichment requests

### Identity Management

Rate limits for identity-related operations via `/v1/identities` (create, update, delete, retrieve):

| Plan Tier          | Max Operations/Second | Max Operations/Minute |
| ------------------ | --------------------- | --------------------- |
| Trial              | 2                     | 100                   |
| Bronze             | 2                     | 100                   |
| Silver / Gold      | 4                     | 250                   |
| Platinum / Diamond | 5                     | 300                   |
| Titanium           | 8                     | 500                   |

#### Capacity Examples

For identity operations (create, update, delete):

| Plan Tier          | Daily Capacity           | Use Case                       |
| ------------------ | ------------------------ | ------------------------------ |
| Trial              | \~144,000 operations/day | Basic account management       |
| Bronze             | \~144,000 operations/day | Small team setup               |
| Silver / Gold      | \~360,000 operations/day | Growing organization           |
| Platinum / Diamond | \~432,000 operations/day | Large team management          |
| Titanium           | \~720,000 operations/day | Enterprise identity management |

### Workspace Info

Rate limits for workspace data retrieval via `/v1/workspaces`:

| Plan Tier          | Max Requests/Second | Max Requests/Minute |
| ------------------ | ------------------- | ------------------- |
| Trial              | \< 1                | 5                   |
| Bronze             | \< 1                | 10                  |
| Silver / Gold      | 1                   | 50                  |
| Platinum / Diamond | 1                   | 75                  |
| Titanium           | 2                   | 100                 |

### Run's Routes Limits

<Info>
  To date, all /runs/xxx routes are subject to the same limit (e.g., 30 requests/minute for TRIAL plans). We are working to refine these quotas per endpoint (status, output, etc.) to better match usage patterns. Plans and limits will be updated in the documentation as soon as these changes take effect.
</Info>

| Plan Tier          | Max Requests/Second | Max Requests/Minute | Rationale                                               |
| ------------------ | ------------------- | ------------------- | ------------------------------------------------------- |
| Trial              | \< 1                | 30                  | Supports 2 concurrent runs @ 10s polling interval       |
| Bronze             | 1                   | 60                  | Supports 2 concurrent runs with more aggressive polling |
| Silver / Gold      | 2.5                 | 150                 | Supports 5 concurrent runs @ 10s polling interval       |
| Platinum / Diamond | 5                   | 300                 | Supports 10 concurrent runs @ 10s polling interval      |
| Titanium           | 10                  | 600                 | Supports 15 concurrent runs @ 10s polling interval      |

Rate limits for polling run results via `/v1/runs/{run_uid}/outputs`. These limits support realistic polling patterns for customers who prefer polling over callbacks.

<Tip>These limits are aligned with concurrent execution limits. For example, with a Silver/Gold plan (5 concurrent runs), you can poll all active runs every 10 seconds with comfortable headroom.</Tip>

#### Capacity Examples

| Plan Tier          | Polling Capacity                         | Use Case                         |
| ------------------ | ---------------------------------------- | -------------------------------- |
| Trial              | Poll 2 runs every 10s                    | Basic polling during development |
| Bronze             | Poll 2 runs every 10s with headroom      | Small-scale polling              |
| Silver / Gold      | Poll 5 runs every 10s, or 1 run every 4s | Team polling operations          |
| Platinum / Diamond | Poll 10 runs every 10s                   | Multi-workspace polling          |
| Titanium           | Poll 15 runs every 10s                   | Enterprise-scale polling         |

<Note>
  **Implementation Details:**

  * Rate limit type: Per-workspace, per-minute
  * Error response: Standard 429 with `X-RateLimit-Type: /v1/runs/outputs`
  * Headers include `X-RateLimit-Remaining` for visibility
</Note>

## Concurrent Execution

For async runs via `/v1/actions/{action-name}/run/async`, we limit the number of concurrent runs and batch processing:

| Plan Tier          | Max Concurrent Runs | Max Batches per Run |
| ------------------ | ------------------- | ------------------- |
| Trial / Bronze     | 2                   | 2                   |
| Silver / Gold      | 5                   | 3                   |
| Platinum / Diamond | 10                  | 5                   |
| Titanium           | 15                  | 8                   |

**What this limits:** Concurrent Runs cap how many runs Edges *processes at once*, not how many you can submit. You can submit as many runs as you need; extra runs are queued and start automatically when a slot is freed up.

**Batching:** Each batch contains maximum **15 inputs**. Batches within a run are executed in parallel (up to "Max Batches per Run"); multiple runs can execute concurrently up to your plan's "Max Concurrent Runs".

For example: one run of 35 inputs → 3 batches (2×15 + 1x5) in parallel for that run.

**Example — \~1,800 inputs:**

| Plan Tier          | Approximate duration |
| ------------------ | -------------------- |
| Silver / Gold      | \~10–15 min          |
| Platinum / Diamond | \~5–8 min            |
| Titanium           | \~4–5 min            |

#### Capacity Examples

For async automations with concurrent execution:

| Plan Tier          | Estimated Daily Capacity        | Use Case               |
| ------------------ | ------------------------------- | ---------------------- |
| Trial / Bronze     | \~50,000-100,000 records/day    | Basic automation       |
| Silver / Gold      | \~200,000-500,000 records/day   | Team automations       |
| Platinum / Diamond | \~500,000-1,000,000 records/day | Large-scale automation |
| Titanium           | 1,000,000+ records/day          | Enterprise automations |

**Example**: With a Platinum or Diamond plan (10 concurrent runs, 5 batches each):

* Process \~500,000-1,000,000 records per day
* Handle complex automations with large results
* Scale to enterprise-level automation needs

## Engagement Mode Rate Limits

For identities configured in **engagement mode**, a separate rate-limiting system applies. These limits are based on the number of **active** engagement identities in your workspace, not your credit-based plan tier.

<Note>Engagement mode identities are designed for LinkedIn automation workflows that don't consume credits. Because of this, dedicated rate limits ensure fair usage across all users.</Note>

More about what's an active engagement identity [here](/v1/identities/engagement#when-is-an-engagement-identity-active-or-inactive)

### Rate Limits by Identity Count

| Identities       | `/v1/actions` (calls/min) | `/v1/actions` (calls/sec) | `/v1/identities` | `/v1/workspaces` | Max Concurrent Runs | Daily API Limit | Batches per Run |
| ---------------- | ------------------------- | ------------------------- | ---------------- | ---------------- | ------------------- | --------------- | --------------- |
| **1–50**         | 25                        | 0.4                       | 100              | 10               | 2                   | 720,000         | 2               |
| **51–200**       | 50                        | 0.8                       | 300              | 30               | 6                   | 3,600,000       | 6               |
| **201–1,000**    | 250                       | 4.2                       | 600              | 60               | 12                  | 14,400,000      | 12              |
| **1,001–5,000**  | 1,250                     | 20.8                      | 1,000            | 100              | 20                  | 72,000,000      | 20              |
| **5,001–10,000** | 2,400 (cap)               | 40                        | 1,000            | 100              | 20                  | 72,000,000      | 20              |

<Tip>As your engagement identity count grows, your rate limits automatically scale up to support higher volumes.</Tip>

### Understanding Engagement Limits

* **`/v1/actions`**: Controls how many action requests you can make per minute/second
* **`/v1/identities`**: Maximum operations per minute for identity management
* **`/v1/workspaces`**: Maximum workspace info requests per minute
* **Max Concurrent Runs**: Number of async runs that can execute in parallel
* **Daily API Limit**: Total API calls allowed per day across all endpoints
* **Batches per Run**: Maximum batches allowed per async run

<Info>If you have both engagement identities and a credit-based plan, the higher limit between the two systems applies for each endpoint.</Info>

## Best Practices

### Optimizing for Rate Limits

1. **Use Async Mode for High Volume**: When processing large datasets, use async mode to benefit from concurrent execution limits rather than hitting real-time rate limits.

2. **Batch Your Requests**: Group related operations together to minimize API calls.

3. **Implement Exponential Backoff**: When you hit rate limits, wait before retrying with increasing delays.

4. **Monitor Your Usage**: Track your API consumption to stay within limits.

### Handling Rate Limit Errors

When you exceed rate limits, you'll receive a `429 Too Many Requests` response.

```json theme={null}
{
  "error": {
    "code": 429,
    "status": "Too Many Requests",
    "details": {
      "Retry-After": "60",
      "X-RateLimit-Limit": "2",
      "X-RateLimit-Reset": "1754402101",
      "X-RateLimit-Type": "/v1/actions"
    },
    "message": "Rate limit exceeded (/v1/actions)"
  }
}
```

### Other Limit Errors to handle

In addition to internal Edges rate limits, you may encounter **LinkedIn-originated rate limits**, which we proactively detect and surface with standardized errors. These are not caused by Edges infrastructure but reflect **LinkedIn’s own protective mechanisms**.

| Error Type | `status_code` | `error_label`   | Origin                                    |
| ---------- | ------------- | --------------- | ----------------------------------------- |
| Internal   | `429`         | *n/a*           | Edges API                                 |
| Detected   | `429`         | `LIMIT_REACHED` | LinkedIn (with protection logic in Edges) |
| Passive    | `429`         | `STATUS_429`    | LinkedIn (propagated, no guardrails)      |

**Handling Strategy (All Cases):**

* Implement **exponential backoff** before retrying
* Monitor for recurring errors per identity
* Avoid retrying immediately and let an extended cooldown period elapse

#### Differentiating `LIMIT_REACHED` with `appendix`

`LIMIT_REACHED` errors now include a **`params.appendix`** (and **`params.timespan`**) so you can tell which limit was hit:

| Origin          | `params.appendix` | `params.timespan` | Meaning                                     |
| --------------- | ----------------- | ----------------- | ------------------------------------------- |
| Third-party API | `API_FUSE_LIMIT`  | `Daily`           | Daily quota reached (e.g. provider fuse)    |
| Third-party API | `API_RATE_LIMIT`  | `Minute`          | Rate limit or flood detection (per minute)  |
| Product         | `MINUTE_LIMIT`    | `Minute`          | Per-minute product limit (calls per minute) |
| Product         | `DAILY_LIMIT`     | `Daily`           | Daily product limit                         |

Use **`appendix`** to choose the right retry strategy (e.g. wait until next minute vs next day). Integrations that only check the `LIMIT_REACHED` label still work but should add handling based on **`appendix`** and **`timespan`** for better behavior.

<Info>
  For **`linkedin-search-people`** in async mode, runs that hit a **monthly** LinkedIn limit (`LIMIT_REACHED`) are automatically retried when the limit resets instead of failing permanently.
</Info>

<Tip>
  `LIMIT_REACHED` errors are triggered by **Smart Limits** — Edges tracks LinkedIn activity on a 24-hour sliding window to prevent account restrictions. [Learn more about Smart Limits](/v1/linkedin/limits).
</Tip>

<Info>This rate limit error response uses a different structure than our standard error format. For details on our typical error responses, see our [Error Reference](/v1/error-reference).</Info>

## Plan-Specific Considerations

### Trial and Bronze

* Focus on development and testing
* Use async mode for production workloads
* Monitor usage closely to avoid interruptions

### Silver, Gold, Platinum, and Diamond

* Suitable for production workloads
* Balance between real-time and async execution
* Consider upgrading for higher volume needs

### Titanium

* Designed for enterprise-scale operations
* Maximum concurrent execution capabilities
* Contact support for custom limits if needed

## Monitoring and Alerts

Track your rate limit usage through:

* API response headers
* Dashboard analytics
* Webhook notifications for quota warnings

## Getting Help

If you consistently hit rate limits or need higher limits:

1. **Review your implementation design** for optimization opportunities
2. **Consider upgrading your plan** for higher limits
3. **Contact support** for custom enterprise solutions

For detailed information about your current plan's limits, check your workspace dashboard or contact our support team.