> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asteroid.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Profiles
> Who a workflow signs in as. What a login profile holds, the Logins page, and how profile groups rotate profiles.
A **login profile** holds everything a workflow needs to sign in and act as one identity. The API
calls a profile an `agentProfile` and a profile group an `agentProfilePool`.
A profile carries:
* attached [secrets](/concepts/credentials) (usernames and passwords with optional TOTP seeds, API keys, cards, custom secrets)
* an Email Inbox
* a sticky IP
* browser cache and session state
A profile is reusable. Many workflows can share one profile, and one workflow can run with a different profile on every execution.
Proxy, captcha solving, stealth, cookies and extensions live on the
[environment](/concepts/environments#custom-environments) the workflow runs on, not on the profile.
Older profiles created through the API may still carry these settings. They apply only when the
environment has no settings of its own.
## In the platform
Open **Logins** in the sidebar. It has four tabs.
| Tab | What it holds |
| - | - |
| **Profiles** | One card or row per profile. Each shows the portals it signs in to, by secret key. |
| **Profile groups** | Groups of interchangeable profiles. See [Profile groups](#profile-groups). |
| **Secrets** | The organization's [secrets](/concepts/credentials), and the templates they are built from. |
| **Requests** | [Requests](/integrate/collect-credentials) sent to other people to fill in a secret. |
Click **Create a login profile** to add one. The form walks through **Details**, **Secrets**,
**Email Inbox** and **Sticky IP**. Click **Ask someone for a login** to send a request instead.
Click a profile to open its drawer. It has four sections:
| Section | What it shows |
| - | - |
| **Overview** | Name, creation date, ID, and the workflows that recently ran as it. |
| **Secrets** | The attached secrets. **Add existing** attaches a saved one. **New secret** creates one. |
| **Email Inbox** | The inbox address and the emails it received. See [Workflow emails](/concepts/emails). |
| **Sticky IP** | Whether the profile keeps one dedicated IP, and its starting cookies. |
Click **Edit** in the drawer header to turn every section into its form, then save once.
Starting cookies apply only to runs with no custom environment. Sticky IP applies to browsers only,
and is set when the profile is created.
## Choosing a profile for a run
An [execution](/concepts/executions) uses at most one profile.
In the builder, open the environment control in the bottom bar. **Runs as** lists the profiles and
profile groups the workflow may use. With one entry, runs never ask. With several, the run form
asks which one to use.
The **Runs as** list belongs to the workflow's environment. Other workflows on the same environment
share it. Click **Copy environment for this workflow** to give one workflow its own list. See
[Profile rows](/concepts/environments#profile-rows).
On the API, pass the profile ID (`agentProfileId`):
```bash theme={null}
curl -X POST https://odyssey.asteroid.ai/agents/v2/workflows/YOUR_WORKFLOW_ID/execute \
-H "X-Api-Key: $ASTEROID_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"inputs": { "account": "acme" },
"agentProfileId": "YOUR_AGENT_PROFILE_ID"
}'
```
Pass a profile group (`agentProfilePoolId`) instead to let Asteroid choose a profile from a [profile group](#profile-groups).
`agentProfileId` and `agentProfilePoolId` are mutually exclusive. Pass one or the other, never both.
See [Call a workflow from your code](/integrate/call-a-workflow) for the full execute call.
## Profile configuration
Every profile gets an inbox at `{prefix}@agentmail.asteroid.ai`. The default prefix is the profile's UUID. Set a prefix to get a readable address. Set it as **Inbox address** when you create or edit the profile. See [Workflow emails](/concepts/emails).
Create and manage profiles on the platform, through the API, or through the SDKs. See the [API reference](/api-reference/overview).
Deleting a profile affects every workflow that references it. Check that no live automation depends on it first.
## Credentials and 2FA
A profile does not store secret values itself. It attaches secrets from the organization's
**Secrets** tab. The profile then exposes `##ITEM_KEY.FIELD##` placeholders. A profile cannot
attach two secrets that share a key.
On the API, attach secrets (`vaultItemIds`) on create or update. On MCP, create them with
`vaultItemsCreate` and attach them with `agentProfileUpdate`. Profile `credentials*` fields are
deprecated.
The same secret can attach to many profiles. See [Secrets & 2FA](/concepts/credentials) for
secret kinds, placeholders, and TOTP seeds.
## Profile groups
A **profile group** holds interchangeable logins for one portal, with the same permissions. You
point a run at the group, and Asteroid picks a profile from it.
Profile groups solve four problems:
* **Credential conflicts**: stop two executions using one account at the same time.
* **Rate limits**: spread requests across several accounts.
* **Availability**: fall back to another profile when one is busy.
* **Manual selection**: remove the choice from every execute call.
Create a group on the **Profile groups** tab with **New profile group**. The form walks through
**Details** and **Members**. The group's drawer has **Members** and **Settings** sections.
### Selection strategies
A profile group uses one of two strategies. The drawer shows it as **Picks**.
| Strategy | Behaviour | Use it for |
| - | - | - |
| **Least recently used** (default) | Picks the profile idle for longest | Spreading load evenly across accounts |
| **Most recently used** | Picks the profile used most recently | Keeping one session warm and cached |
Least recently used rotates fairly. With profiles A, B and C, an execution after B picks whichever of A or C idled longest.
Most recently used concentrates work on fewer profiles. It keeps browser state and authenticated sessions warm.
### Concurrent use
`allowConcurrentUse` decides whether a busy profile can be picked again. The drawer shows it as
**Shared use**.
| Value | Behaviour |
| - | - |
| `false` (default) | Skip any profile tied to an active run. Strict credential isolation. |
| `true` | Pick any profile, busy or not. Maximum availability. |
With `allowConcurrentUse: false`, a request fails immediately when every profile in the group is busy. The error says no profile is available. Add more profiles, allow concurrent use, or send `"onCapacityLimit": "queue"` on the execute call. The execution is then accepted as `queued` and starts when a profile frees. See [Queue when capacity is full](/integrate/call-a-workflow#queue-when-capacity-is-full).
### Group constraints
An execute call takes `agentProfileId` or `agentProfilePoolId`, never both.
```json theme={null}
{ "agentProfilePoolId": "pool-456" }
```
* Every profile in a group belongs to the same organization.
* A group name is unique within an organization.
* A profile from another organization cannot join the group.
* A group needs at least one profile before an execution can use it.
* Remove the last profile and no new execution can use the group.
Match the group size to your parallelism. Five simultaneous runs need at least five profiles. Add one or two spare profiles for peak load.
A profile group works with every profile feature: attached secrets, TOTP seeds, Email Inbox, and browser state. The selected profile's configuration applies exactly as if you had named it yourself.
Pass a profile or a profile group on the execute call
How Asteroid stores and uses secrets
The Email Inbox each profile owns
Where the workflow runs, and its browser settings
How Asteroid protects stored credentials
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.