Our team is still aware of this request, but itâs been de-prioritized since flows can be run an unlimited number of times without the need to worry about burning credits.
Have you checked out our updated subscription plans? Feel free to send us an email at help@parabola.io and we can find a time to discuss subscription plans to ensure youâre not burning credits when building flows!
Hi Daniel,
Sorry for the misunderstanding.
I meant credits from APIs as the vast majority of commercial APIs work with credits (translation like Deepl, enrichment like Hunter, etc.).
I did not mean Parabola Credits. 
i feel like there is a mistunderstanding about this issue.
Parabola would be so powerful if we could run APIs without burning the subscription of the API itself.
I would really like to use it for contact enrichment etc but APIs like rocketreach have a high cost per credit which make Parabola a no-go.
Thanks
Totally understand where youâre coming from. Unfortunately, we do not have any intermediary API buffer on our product roadmap. It sounds like youâd benefit from error handling that continues making requests to an API when a previous row does not return data.
If you do run into this issue again, might I suggest creating a reference file that contains all company names that have returned successfully?
You could then use a Find overlap step between your step before the API request and your reference file to remove any companies that you have successfully queried.
Thank you for your answer,
Is adding a checkbox to purely and simply ignore errors and proceed is not possible technically on your end?
Thanks a lot for your help!
That sounds ideal, though it would require extensive changes to our backend to fully implement this. A ticket has been logged with our engineering team.
For transparency, they are prioritizing other projects at the moment, so using a Find overlap step could be the best workaround in the interim.
If you have any questions about setting up a Find overlap step, feel free to email us at help@parabola.io.
I will make use of your idea, thank you.
The fact that I cannot go directly from Removing the limit rows step to running the flow live without recalculating everything is the number one reason for wasting my API credits.
Hope this improves some day as your tool really makes working with APIs easy!
Adding a related use-case for the ability to turn off enrichment steps when the flow isnât actually running in live mode:
When you duplicate a flow, the flow necessarily refreshes/sends data down all of the steps, even before the editor is opened. This makes duplicating flows problematic without consideration of all the API enrichment steps that are set up.
I often want to duplicate a flow and modify it, but I donât want to hit APIs that are set up in enrichment steps. (This is especially true in case where thereâs Production vs. Sandbox environments, but equally true if trying to minimize calls to an API that uses a credits metering system).
My envisioned process would be:
-set enrichment steps to âSend requests only when flow is running in live modeâ
-duplicate the flow
-in duplicated flow, modify whatever needs changing
-switch those enrichment steps to âSend requests while in draft modeâ if necessary, or just run the flow in live mode.
A slight variation would be:
Before making changes to a flow, I want to duplicate it and put it in an Archive folder, in case the changes Iâm making end up not working.
But for reasons mentioned above, thatâs complicated by enrichment steps that are triggered when flow is duplicated.
Hello! 
Wanted to share that we have introduced a small (but useful!) feature that may alleviate some pain points when building with our API steps.
We have introduced a toggle on our âLimit Rowsâ step (see screenshot below) that allows for users to have the step enabled in draft mode, but allow all rows through when the published version runs. This should allow builders to have a quicker feedback loop when building with large datasets or slow running steps, as well as make api calls less expensive while building.
Please let us know if you have any questions!
