> ## 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.
# Overview of Identity Modes
> Choose sync or managed accounts, then select direct, auto, or managed identity mode when you run an action.
Two decisions shape how Edges runs LinkedIn actions: **how accounts are provided**, and **how a run selects an identity**. Capacity, cost, and which actions you can call all follow from these.
***
## How accounts are provided
There are two ways to give Edges a LinkedIn account to work with — **BYO** (bring your own accounts) or **Managed**. Everything else — modes, rotation, limits — follows from this one choice.
| | **BYO** — sync your users' accounts | **Managed** |
| - | - | - |
| **Whose account runs the action** | Your user's | An account Edges provisions and operates |
| **Setup** | Chrome Extension, native login, or cookies | None — set `identity_mode: "managed"` |
| **Cost** | Standard credits | 1.5× standard credits, plus a possible monthly cost at higher volumes |
| **Capacity is bounded by** | Per-identity [action limits](/v1/linkedin/limits) | Your [plan's rate limits](/v1/runs/rate-limits) |
| **Best for** | Outreach, anything attributable to a person | Enrichment and search at volume, with no accounts to manage |
The two choices don't change any quota — they change **which limit system you have to plan around**. In BYO the per-identity action limits are your ceiling. In Managed they're ours to absorb, and your ceiling is your plan. See [How Limits Work](/v1/limits/how-limits-work).
BYO and Managed aren't exclusive. You can sync accounts for outreach — where the action has to come from a real person — and use managed for enrichment and search, where it doesn't matter who ran it.
### BYO — sync your users' accounts
Bring your own accounts: connect your users' own LinkedIn accounts through the [Chrome Extension](/v1/linkedin/chrome-extension), [native LinkedIn login](/v1/api/linkedin/authentication), or by [providing cookies](/v1/api/integrations/connect).
**Use it when**
* The action must be attributable to a specific person — messages, invitations, InMail, profile views
* You are building on behalf of users who have their own LinkedIn accounts
* You need data only that account can see, such as its own connections or profile viewers
**How capacity works**
Each connected account carries its own allowance for each action — connection requests, profile visits, messages, enrichments. These are the [Smart Limits](/v1/linkedin/limits) quotas: **ours**, set deliberately below what LinkedIn tolerates so the account stays usable. They are per identity, not per workspace, so adding accounts adds capacity while pushing one account harder does not.
A newly connected account does not start at full capacity. See [Identity Ramp-Up](/v1/limits/identity-ramp-up) — this is the most common reason a limit is hit sooner than the quota table suggests.
To spread work across several of your own accounts automatically, use `identity_mode: "auto"` — see [Auto Mode](#auto-mode) below.
**Limitations**
* Your users have to complete a connection step
* Sessions expire and accounts occasionally need reconnecting
* Capacity is bounded by how many accounts you have and what licence each holds
### Managed accounts
Run actions without owning or connecting any LinkedIn account. Edges provisions and operates the accounts, handles their warm-up and rotation, and replaces them when needed.
```json theme={null}
{
"identity_mode": "managed"
}
```
That is the entire setup.
**Use it when**
* You are extracting or searching public data at volume
* You have no user accounts to use, or don't want to use them
* You are reselling data extraction and need capacity that isn't tied to individual users
* You want to start immediately without a connection flow
**How capacity works**
This is the important difference. **You never meet a per-account limit — your plan's rate limits are your ceiling.** The per-identity quotas still exist behind the scenes; keeping enough capacity available to absorb them is our job, not yours. Edges sizes the underlying pool to meet the throughput your plan allows.
At higher volumes the pool is **dedicated to your workspace** and fitted to it: sized against your plan and the throughput you actually need, rather than drawn from a shared allocation. Because that provisioning is specific to each workspace, an additional monthly cost can apply.
Dedicated pools are set up with you rather than self-served. Start from the [LinkedIn Integration page](https://app.edges.run/integrations/linkedin) or talk to your Edges contact, and we will size it against the volume you're planning for and confirm the setup timeline then.
The accounts behind managed mode are provisioned through third-party accredited services and operated entirely by Edges. You do not get direct access to them, and you never handle their credentials, cookies or warm-up.
See [Rate Limits](/v1/runs/rate-limits) for what your plan allows.
**Limitations**
* **1.5× standard credit cost**
* **Not available for every action.** Anything that reads data belonging to a specific account — [profile viewers](/v1/api/actions/linkedin-extract-profile-viewers), your own connections, your own messages — needs that account, so it requires a synced identity in `direct` mode
* No attribution to a person, which rules it out for outreach
### Choosing
Messages, invitations, InMail, or reading that account's own data → **sync your users' accounts** and run in `direct` mode. Managed cannot do these.
Yes, and their combined capacity covers your volume → use them, with `identity_mode: "auto"` to spread the load.
→ **Managed**. If your volume is beyond what a shared allocation comfortably serves, that becomes a dedicated pool sized with you.
### When an account goes invalid
Synced accounts occasionally need reconnecting — a session expires, or LinkedIn asks for a verification step. Edges surfaces this through [LinkedIn integration webhooks](/v1/identities/linkedin) so you can prompt the user, and runs blocked by it are recoverable once the account is valid again.
Watch for an invalid integration with webhooks, and reconnect it.
Restart the runs that stopped while it was invalid.
In managed mode there is no account for you to fix. The pool is Edges's to monitor and maintain, and an account that stops working is taken out and replaced without anything reaching your integration.
If something looks wrong on either side, contact us at [support@edges.run](mailto:support@edges.run) or through the chat in the Edges app.
***
## How a run selects an identity
Identity modes control how Edges uses your integration accounts when executing actions. You can choose between three modes depending on your needs for control, automation, and cost.
## Available Identity Modes
The identity mode to use: `direct`, `auto`, or `managed`
The identities to run on. Required for `direct`. Most actions take exactly one — see [Direct Mode](#direct-mode) for when more than one is accepted.
## Mode Comparison
| Mode | Control Level | Setup Required | Cost | Best For |
| - | - | - | - | - |
| **Direct** | Full control | Manual selection | Standard | Specific accounts, compliance |
| **Auto** | Automatic distribution | Configure accounts | Standard | High-volume, resilience |
| **Managed** | No account management | None | 1.5x standard | Enrichment and search at volume |
**Managed mode cost:** Using `managed` identity mode costs **1.5×** the standard credit cost for all actions. Calculate your costs with: `current_cost x1.5`.
## Direct Mode
**Full control over which accounts to use**
Use `direct` mode when you need precise control over which integration accounts execute your actions.
### Use Cases
* Actions requiring specific accounts (e.g., [`linkedin-extract-profile-viewers`](/v1/api/actions/linkedin-extract-profile-viewers))
* Using only a subset of your identities (e.g., sales team accounts only)
* Separating company-level calls from user-specific calls
* Compliance requirements for account attribution
### Implementation
Name the identity the run should use:
```json theme={null}
{
"identity_mode": "direct",
"identity_ids": ["identity-1"]
}
```
### Example Request
Extract the profile viewers of one specific account:
```bash theme={null}
curl --request POST \
--url https://api.edges.run/v1/actions/linkedin-extract-profile-viewers/run/live \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'X-API-Key: ' \
--data '{
"parameters": {},
"identity_mode": "direct",
"identity_ids": ["identity-1"]
}'
```
**One identity, unless the action can rotate.** Actions that read data belonging to a single account — profile viewers, your own connections, your own conversations, and anything that sends on someone's behalf — accept exactly one entry in `identity_ids`. Passing more returns `400` with `BAD_PARAMETERS` and the message *"this action does not support account rotation"*.
To spread work across several of your own accounts, use [`auto`](#auto-mode) instead of listing them here.
For actions that do support rotation, `direct` distributes across the identities you list, preferring the one used least.
Edges will filter out accounts that aren't valid for the current action. For example, using LinkedIn identity IDs for a Sales Navigator action will result in a `NO_VALID_ACCOUNT_CONFIGURED` error.
You must provide at least one valid identity ID when using `direct` mode.
## Auto Mode
**Automatic distribution across all available accounts**
Use `auto` mode for automatic load balancing across all your valid integration accounts.
### Use Cases
* Processing large batches of inputs
* Running parallel actions for better performance
* Actions with strict rate limits (visits, connections)
* Building resilient systems that continue working if some accounts become invalid
### Implementation
```json theme={null}
{
"identity_mode": "auto"
}
```
You still need to configure identities and integration accounts yourself. Ensure you have at least one account with the right integration and subscription level for the action.
If you pass both `auto` and `identity_ids`, the request runs in `direct` mode — naming identities is an explicit choice, so it wins.
## Managed Mode
**Run actions on accounts Edges provisions and operates**
Use `managed` mode to execute actions without managing any integration accounts yourself.
### Benefits
* **No account setup required** - Works even without any integration accounts
* **Automatic load distribution** - Optimal performance and parallelism
* **No account issues to handle** - Warm-up, rotation and replacement are Edges's responsibility. Your throughput is still bounded by [your plan's rate limits](/v1/runs/rate-limits)
* **Simplified workflow** - Focus on your business logic, not account management
### Implementation
```json theme={null}
{
"identity_mode": "managed"
}
```
**Limitation:** You cannot use `managed` mode for actions that require specific accounts (e.g., [`linkedin-extract-profile-viewers`](/v1/api/actions/linkedin-extract-profile-viewers)). For these actions, use `direct` mode with the specific account that owns the data.
**Cost consideration:** Managed mode uses Edges's account pool and costs **1.5x** the standard credit cost for all actions.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.