Rate Limits

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

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

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.

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

For async actions, different concurrent execution limits apply (see Concurrent Execution below).

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

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.

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.

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.

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

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

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.

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.

More about what’s an active engagement identity here

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

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

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

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

Best Practices

Optimizing for Rate Limits

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.
Batch Your Requests: Group related operations together to minimize API calls.
Implement Exponential Backoff: When you hit rate limits, wait before retrying with increasing delays.
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.

{
  "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.

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.

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.

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.

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:

Review your implementation design for optimization opportunities
Consider upgrading your plan for higher limits
Contact support for custom enterprise solutions

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

Getting Started

Essentials

Build with Edges

Overview

Plan Tiers

API Rate Limits

Real-time Actions

Capacity Examples

Identity Management

Capacity Examples

Workspace Info

Run’s Routes Limits

Capacity Examples

Concurrent Execution

Capacity Examples

Engagement Mode Rate Limits

Rate Limits by Identity Count

Understanding Engagement Limits

Best Practices

Optimizing for Rate Limits

Handling Rate Limit Errors

Other Limit Errors to handle

Differentiating `LIMIT_REACHED` with `appendix`

Plan-Specific Considerations

Trial and Bronze

Silver, Gold, Platinum, and Diamond

Titanium

Monitoring and Alerts

Getting Help

​Overview

​Plan Tiers

​API Rate Limits

​Real-time Actions

​Capacity Examples

​Identity Management

​Capacity Examples

​Workspace Info

​Run’s Routes Limits

​Capacity Examples

​Concurrent Execution

​Capacity Examples

​Engagement Mode Rate Limits

​Rate Limits by Identity Count

​Understanding Engagement Limits

​Best Practices

​Optimizing for Rate Limits

​Handling Rate Limit Errors

​Other Limit Errors to handle

​Differentiating LIMIT_REACHED with appendix

​Plan-Specific Considerations

​Trial and Bronze

​Silver, Gold, Platinum, and Diamond

​Titanium

​Monitoring and Alerts

​Getting Help

Overview

Plan Tiers

API Rate Limits

Real-time Actions

Capacity Examples

Identity Management

Capacity Examples

Workspace Info

Run’s Routes Limits

Capacity Examples

Concurrent Execution

Capacity Examples

Engagement Mode Rate Limits

Rate Limits by Identity Count

Understanding Engagement Limits

Best Practices

Optimizing for Rate Limits

Handling Rate Limit Errors

Other Limit Errors to handle

Differentiating `LIMIT_REACHED` with `appendix`

Plan-Specific Considerations

Trial and Bronze

Silver, Gold, Platinum, and Diamond

Titanium

Monitoring and Alerts

Getting Help