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

​

Resource Limits

The following tables outline the key limits for each subscription tier:

​

Rate Limits

Pinkfish enforces rate limits on API requests to protect platform stability and ensure fair usage. 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.

​

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

For information on credits and usage-based billing for services that extend beyond these limits, please refer to our Credits documentation.