👤 For teams creating and managing integrations in Pipefy Integrations Hub
🔐 Requires Super Admin profile in Pipefy
🎯 Level: beginner-intermediate
Before creating the first integration in Pipefy Integrations Hub, two types of knowledge make a real difference: understanding how the platform processes flows at scale, and correctly configuring the Service Account that will authenticate everything interacting with Pipefy. Ignoring either one is the origin of most problems that surface after integrations are already in production.
This article covers the technical limits that define platform behavior under load, and the Service Account model that separates integration authentication from personal credentials. With both of these clear, flow construction starts on the right foundation.
📖 What you will understand here:
How Pipefy Integrations processes executions (and the limits that shape your flow design)
Understanding how the platform executes a flow, and within which envelope of time, memory, and concurrency it operates, is what separates an integration that scales from one that breaks in production.
How the platform processes executions
All integrations are processed asynchronously. When a flow is triggered, the system immediately confirms receipt and puts the execution in a queue. Processing happens next, without blocking whoever fired the trigger.
This model has one important practical implication: the system that fired the event does not wait for the result. For most flows, this is exactly the correct behavior. For flows where the originating system needs a response before continuing, as in a synchronous webhook, the integration design needs to account for this from the start.
And here is a concrete limit: the flow has 30 seconds to acknowledge a webhook trigger. In a synchronous scenario, this means the logic that needs to return a response to the originating system must be lean enough to fit within that window. Heavy calculations, slow external calls, or large data manipulations do not belong in the synchronous path. They should run asynchronously, after the acknowledgment.
The limit of 50 simultaneous executions
The platform allows up to 50 flows running at the same time per organization. When this limit is reached, subsequent executions enter a waiting queue and are processed as soon as a slot opens. The flow does not fail: it waits. But wait time grows proportionally to volume above the limit.
For low-volume operations, this limit never appears. For operations that fire integrations in bulk, this limit defines the real throughput of the integration and needs to be on the radar before going to production.
The most effective way to operate within the concurrency limit in high-volume processes is to work with smaller batches and controlled intervals between sends. Instead of firing a thousand executions at once, sending in groups of 40 to 45 keeps volume below the ceiling of 50 and avoids queue buildup.
Governance limits that affect flow design
Beyond the concurrency limit, certain technical parameters define the operating envelope for each individual execution.
5-minute timeout per execution
Each flow execution has a maximum time of 5 minutes. If the flow does not complete within this limit, the execution is interrupted. Flows with many chained actions, calls to slow APIs, or processing of large data volumes in memory are the main candidates for hitting this ceiling.
The impact on design is direct: long flows need to be broken up. Sub-flows, loops with smaller batches, and HTTP calls with properly configured timeouts are the tools to keep each execution within the limit.
512 MB of RAM per execution
Each execution operates with up to 512 MB of memory. For most integration flows, this limit is never relevant. It starts to matter when the flow loads large files into memory, processes extensive JSON payloads, or uses Code with heavy processing. If the flow handles documents, images, or high-cardinality datasets, it is worth estimating the memory footprint before going to production.
One specific note on files: the 10 MB limit applies ONLY to the Files utility (the files helper). Data manipulation via code and receiving data files are not subject to this limit, but they are still subject to the 512 MB memory ceiling of the execution. In other words: a file can enter the flow through a path that does not go through the Files utility, but if its in-memory manipulation exceeds 512 MB, the execution breaks anyway. The best practice is to never load the entire file into memory, filter columns, process in batches, and work by streaming whenever possible.
Automatic throttling kicks in when a single account generates excessive load that affects platform stability for other users. The system rejects abusive requests without prior notice. This is especially relevant in mass migrations or initial data loading processes: distribute volume over time instead of processing everything at once.
In summary, three design decisions resolve most problems with these limits: fragment the work, smaller batches, sub-flows, to fit within the 5 minutes and 50 simultaneous executions; keep memory lean, no loading entire files, process in batches, to respect the 512 MB; and distribute volume over time in large loads, to avoid triggering the queue or throttling.
Service Account: authentication without personal credentials
A Service Account is a service account created specifically to authenticate integrations. It does not represent a human user. It has its own email address, a Client ID, and a Client Secret, and it is this combination that Pipefy Integrations uses to authenticate and operate within the pipes it needs to interact with.
The reason to use a Service Account instead of an employee's credentials is simple: personal credentials have an owner. When that employee leaves the company, changes roles, or has their access revoked, every integration that used their credentials stops working. A Service Account exists independently of any individual and can be managed, audited, and deactivated without impact on any user.
Naming and permissions: decisions that matter before you create
Two points deserve attention before creating the first Service Account, because they are difficult to correct after integrations are already in use.
Descriptive naming from the start. A name like "Integration-Onboarding-HR" or "SA-Finance-ERP" communicates purpose, origin, and destination. A generic name like "SA1" or "Test" becomes a traceability problem within weeks. The description field is also a required real fill: explain what this account exists for, which systems it connects, and who the technical owner is.
The correct permission is Pipe Administrator. This is the role that needs to be assigned to the Service Account in each pipe it will interact with. Without this permission, the integration cannot operate within the pipe. This step is the most frequently forgotten during initial setup and is the most common cause of flows that trigger but do not execute the expected actions.
Before moving on, confirm that you understand:
☐ What happens when more than 50 flows attempt to execute simultaneously
☐ Why the 5-minute timeout affects the design of flows with high data volume
☐ The difference between a Service Account and a Pipefy user's credentials
☐ What permission the Service Account needs in each pipe
