> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pinkfish.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Limits
> Platform limits
Pinkfish implements resource limits to ensure optimal performance, reliability, and fair usage across all customers. These limits are designed to maintain platform stability while providing flexibility for your workflow needs.
## Plan Overview
For detailed information on available plans and pricing, please refer to our [Pricing](/billing/pricing) documentation.
## Resource Limits
The following tables outline the key limits for each subscription tier:
| Resource | Starter | Pro | Team | Enterprise |
| :-------------------------- | :-----: | :-: | :--: | :--------: |
| **Concurrency** | | | | |
| Concurrent Browser Sessions | 1 | 1 | 2 | 5+ |
| Concurrent Workflow Runs | 5 | 5 | 20 | 200+ |
| **Organization** | | | | |
| Team Members | 1 | 1 | 10 | Unlimited |
| Additional Organizations | 0 | 0 | 2 | 5+ |
| **Connections** | | | | |
| Browser Operator Logins | 1 | 5 | 10 | 100+ |
| Custom API Connections | 0 | 5 | 10 | 100+ |
| **Collections** | | | | |
| Datastore Collections | 1 | 1 | 10 | 100+ |
| File Storage Collections | 1 | 1 | 10 | 100+ |
| Vault Collections | 0 | 0 | 10 | 100+ |
## Rate Limits
Pinkfish enforces rate limits on API requests to protect platform stability and ensure fair usage.
| Service | Hourly Limit | Daily Limit | Description |
| :---------------- | :----------: | :---------: | :-------------------------------------------------------------------------------------------------------------------------- |
| Platform MCP | 20,000/hr | 200,000/day | All MCP tool calls — code execution, agent memory, LLM calls, and any service accessed *through an MCP tool* |
| PinkConnect | 25,000/hr | 250,000/day | All proxy requests through PinkConnect |
| Embedded services | 50,000/hr | 500,000/day | All authenticated platform service endpoints — **Datastore reads/writes/queries**, search, browser, LLM, file storage, etc. |
**Where do Datastore operations count?** Datastore reads, writes, and queries are served by the platform's embedded service endpoints, so they count against the **Embedded services** limit of **50,000/hr (500,000/day)**. The one exception: when a workflow reaches a Datastore *through an MCP tool call*, that tool call is also metered by the **Platform MCP** limit (20,000/hr) — the lower of the two ceilings then governs that path. Direct Datastore access from a workflow is bound only by the 50,000/hr embedded-services limit.
When a rate limit is exceeded, the API returns a `429 Too Many Requests` response with a `Retry-After` header indicating how long to wait before retrying.
Rate limits use a sliding window algorithm, so usage is measured continuously rather than resetting at fixed intervals. Enterprise customers can request increased rate limits — contact your account team.
### How the limit is scoped
Each rate limit is counted **per user, per organization** — the counter key is the combination of the individual user and the organization the request runs in. This has a few important consequences:
* **Per user, not shared org-wide.** Every member of an organization has their own independent budget for each service (for example, 50,000/hr of embedded-service requests each). Two users in the same org do not draw from a single shared pool — User A hitting their limit does not throttle User B.
* **Per organization, not per user globally.** The counter is scoped to the `(user, organization)` pair, so the same person operating in two different organizations has two separate, independent budgets. Usage in Org X does not count against the same user's budget in Org Y.
* **The organization itself has no single aggregate cap.** There is no org-level "50,000/hr for the whole org" bucket — the limit is always evaluated at the `(user, organization)` level. An organization's total throughput is effectively the sum of its active users' individual budgets.
In short: the budget is allocated to a specific **user inside a specific organization**. It is neither a single per-organization pool shared by all members, nor a single per-user pool shared across all of that user's organizations.
### How triggered runs are counted
Workflows do not have to be started by a human in the UI — they can be launched by a **schedule**, an **inbound email trigger**, or an **API / webhook trigger**. In every case, the run executes under a specific user identity within a specific organization (the credentials/identity the trigger is configured with), and **all requests made during that run count against that executing user's budget in that organization** — exactly as if that user had started the run manually.
So:
* A scheduled workflow that runs every 5 minutes counts every Datastore read/write (against the embedded-services budget) and every MCP tool call (against the Platform MCP budget) it makes against the budget of the user the schedule runs as, in that org.
* Workflows created and triggered under **different user accounts** are metered separately, each against its own `(user, organization)` budget — because each run carries that user's identity.
* Email-triggered and API-triggered runs are attributed to the user/organization tied to the trigger, and are counted against that user's budget in that org just like any other request.
If a single account is responsible for a high-frequency schedule (for example, a workflow on a 5-minute cron that performs many Datastore operations per run), that one account can approach its own 50,000/hr embedded-services ceiling — or its 20,000/hr Platform MCP ceiling, if the work routes through MCP tools — while other users in the same organization are unaffected.
### Storage Capacity
| Collection Type | Maximum Items |
| :----------------------- | :--------------------: |
| Datastore Collections | 100,000 per collection |
| File Storage Collections | 1,000 per collection |
| Vault Collections | 50 per collection |
Enterprise plans can increase limits with add-ons: - Browser Plus: +5
concurrent browser sessions - Organization Plus: Additional organizations
For information on credits and usage-based billing for services that extend beyond these limits, please refer to our [Credits](/billing/credits) documentation.