Recently, I realised that my API is being executed two times upon each trigger in the workflow. Can’t understand if it’s a bug or feature. This is what I do:
Designer: Group Prompt with a type of content of my API, data to display is left empty.
Workflow: Trigger “Display data” in the Group with data to display specified. (e.g. API - Prompt)
Workflow: Trigger “Create new thing” where I pass a parameter of the response received in the Group. (e.g. Group Prompt’s Prompt’s items’ parameter).
Workflow: Trigger “Go to page” with a unique id of the newly created thing (i.e. it goes to the same page with the “replace history” flag).
Looks simple, but below is what actually happens:
A new thing is created with the param received in mget package (e.g. debug shows like it’s been created even before I reach the step of creating a thing - even just before finishing the Display data trigger)
Renders the page with the ID and shows the param received in “doapicallfromserver” package which is different from that has been created in the thing (i.e. that means it’s another query - as each time I receive a unique value from the API)
Then, when the browser receives “mget” package the page is refreshed with the param in it.
I’m confused… can anyone help me understand what’s going please?
Running into a similar issue. We are using an API we built ourselves in Google Cloud functions.
We are using it to run an API workflow on a list (it’s not the list API but rather the API called to generate the list itself, meaning it should only get called once to generate the initial list), but it gets called twice, sometimes at the exact same time, and sometimes 1-2 seconds apart.
I am having the same issue with different APIs. The workflow has an action which runs the api to post information to a website and after it successfully posts the information to the site I get an error stating “We are already processing same request, please try again after few mins”. It does not affect my information but it just n o look good to end user.
We actually just noticed that we needed to change the ‘Use as’ field of the API in the API Connector to ‘Action’ instead of ‘Data’ so that we can just run the action at the beginning of the workflow and then reference it once instead of plugging the same api in as a data source in multiple fields on one action. Maybe the same can be done for others to fix their issues.
Same issue here. In my case, it shows that it’s running more than twice, and in my application, this is resulting in importing a set of data more than once. Are API calls reliable from bubble cause this is a major issue…?
I’m still getting this issue. sometimes it calls twice but others it calls 4, 6, 8, 10 times per submission. it’s making it untenable for me to use my own api(s). is this a known bug?
I haven’t seen anything here since October 2023, but I am having this issue. I do, though, have a theory that I’ll posit that others may be able to dispel or confirm. When I was setting up my first API connector (and partly guessing my way through it), I noticed that Bubble was initiating the API connector up to four times (note that I had mistakes in the set up). I wonder if Bubble retries a connection when it doesn’t get a timely response back? So if an API is slow responding… Bubble tries it again. The API I am connecting to is one I have written on AWS Lambda…and it works with other services just fine… but I can see the the CloudWatch log that Bubble is clearly calling it multiple times even though the back-end workflow should be calling it just once… and all of the other actions in the Workflow clearly only execute once.
After rethinking the implementation of the API running on AWS Lambda, I broke it into two parts – An API receiver that takes in the data from Bubble, verifies the input, sends it to an SQS queue, and return the result of the verification step. This takes less than 2 seconds and Bubble does not retry the API call. A second Lambda function reads from the queue and processes the data. This sometimes can take up to 15 seconds… but Bubble isn’t waiting. This second consumer Lambda function then calls an API workflow in the Bubble application. I no longer have multiple API calls coming from the Bubble app.
