👤 For technical users and developers integrating external systems with Pipefy
🔐 Available on plans with API access
🎯 For anyone deciding whether a write operation belongs inside the pipe, inside the flow or outside, in the API
The account is past its early days. Pipes are running, automations are live and the team trusts the process to carry the day to day. Then the operation that native automations can't handle on their own shows up: updating hundreds of cards at once after a policy change, clearing a field in bulk before a new cycle, syncing a piece of data that originates in another system. The question that stalls you isn't which command to type. It's where that operation should live.
By the end of this article, you'll know how to choose between three write paths in Pipefy, native automation, HTTP action inside the flow and GraphQL API from outside, with clear criteria of volume, data origin and maintenance, so you don't reach for the API when the problem could be solved closer to home.
📖 What you'll understand here:
The three write layers
Every operation that changes data in Pipefy can happen in one of three layers, and each one solves a specific kind of case well.
The first is native automation, inside the pipe itself. It covers what happens in response to a process event: a card moves phases, a field gets filled, a deadline passes. It's the easiest layer to maintain because whoever owns the process can see the rule in the interface, no code required.
The second is the HTTP action inside the flow. It comes in when the logic still belongs to the process but needs something native automation doesn't do: a call with its own rule, a consistent field cleanup, an update that depends on an earlier step in the flow. It stays inside Pipefy, stays traceable, and it's the subject of the article *The HTTP action*.
The third is the GraphQL API, from outside. It's the right layer when the operation doesn't come from a process event, but from an external system or a one-off bulk maintenance need. That's the case for syncing data living in another piece of software, or applying a bulk fix nobody will repeat every week.
The question separating the three isn't technical, it's about origin. If the operation responds to a process event, it belongs to the process (native or HTTP action). If it comes from outside or is a one-off intervention, the API is the place.
The decision matrix
Before opening the GraphQL IDE, three questions resolve most cases.
Where does the operation originate? If the trigger is a process event, start with native automation and only move up to an HTTP action if native can't reach it. If the trigger is external (a system pushing data) or a one-off maintenance task, the API makes sense.
What's the volume and how often? A single bulk correction is a natural API candidate. An operation that repeats on every card, every day, almost always belongs in the flow, because that's where it stays visible and maintained by whoever owns the process.
Who maintains this six months from now? A native automation is read by any admin in the interface. An HTTP action still lives inside Pipefy. An external integration lives outside, depends on a connection that needs an owner and disappears from the radar of anyone who only looks at the pipe. The farther from the process an operation lives, the more governance care it demands.
Before choosing the API for a bulk operation, check your plan's ceiling. The Pipefy API limits you to 500 requests every 30 seconds, and going over that blocks new calls for 5 minutes. For bulk updates, the recommendation is to work in batches of up to 30 cards at a time. High volume isn't a blocker, but it's a decision variable: an operation that exceeds the ceiling needs to be split, and that changes the account's maintenance effort.
- Learn more: How to use the Pipefy API
Updating, clearing and removing are different decisions
Once you've decided the operation is an API job, the type of write changes the criteria. Updating a value, clearing a field and removing a card aren't the same thing with rising risk. They're decisions of a different nature.
Updating is the lowest-consequence operation. You swap one field value for another. In bulk, each card is its own call stacked in the same request, which pairs well with the batch of up to 30 cards the plan ceiling recommends. The risk here is scale, not loss: get the value wrong and you fix it with another update.
Clearing looks like updating, but emptying a field has a detail that separates the types. For text fields, clearing means assigning an empty value. Attachment fields, though, need separate handling, because an attachment isn't a text you erase by writing over it. Before clearing attachments in bulk, confirm that field type's specific behavior in the Help Center, because treating an attachment like text is the most common way a bulk cleanup fails silently.
- Learn more: How to clear fields in bulk via API
Removing is the only write operation with no way back. Deleting a card erases its history, and in auditable processes that's rarely what you want. Before deleting in bulk, ask whether you need to remove for good or just take the card out of the active flow. If it's the latter, archiving preserves the record and is usually the correct architectural decision. Deleting should be the exception reserved for data that truly can't exist, not the shortcut for "get out of my way."
The question that protects the process: does this operation need to be irreversible? If the answer isn't a firm yes, there's probably a path that preserves the history.
- Learn more: How to delete cards in bulk via API
The rule that doesn't change: Service Account, never a personal token
Regardless of layer and operation type, one thing is non-negotiable in production: authentication uses a service account, not the personal token of whoever built the integration.
The reason is continuity. A call authenticated with a personal token stops working the day that person leaves the company or has their access changed. The bulk operation that cleared fields, the sync that ran every night, all of it stops at once and without warning. The service account decouples the integration from any individual, and it's what keeps the operation alive when the team changes.
If you find personal connections in old automations or recipes, the good practice is to swap them now, not wait for the process to break to find out.
- Learn more: Technical fundamentals and Service Account
Before moving on, make sure you understand:
☐ Why the operation's origin (process event vs. external system) decides the layer before volume does
☐ That updating, clearing and removing are decisions of a different nature, not the same operation with more risk
☐ That your plan's call ceiling is a decision variable, not an implementation detail
☐ That archiving preserves history and deleting has no way back, and which of the two your process actually needs
