Include errors in response and allow workflow actions to continue

Is this working correctly on 200s?

The API I am calling correctly returns a 200 in the status code but in the back end the only field that is available in the workflow is returned_an_error being “no”. Despite 200 coming back from the API.

The assumption here is that the ONLY non-error status code is 200?

Not really sure that is true.

Exactly. A 20x response is technically not an error. But some API will return 200 but have a payload for error. What you need to do is to merge the good payload with the error payload and enter it manually. Use conditionnal to detect error message. In this case, using continue workflow doesn’t matter because the API doesn’t return an error code le 40X or 50x.

The issue is that you have no way to tell what the API returned as a response.

Despite the fact the the API DID return a reponse code, Bubble simply refuses to pass it on to you if “returned_an_error” is no.

Really don’t think this is how it should be working.

I don’t agree. But I don’t understand what you mean by

When you initilize the API, you have the response. But in this case, you need to enter the response manually by merging this response and the error payload.
Let’s say you have a good response:

{"itemid":"123456","success":"true"}

The error payload is

{"error":"error message","success":"false"}

You will manually enter:

{"itemid":"123456","error":"error message","success":"false"}

Also, you can use “raw body” that should be available, but not parsed.

The alternative here is to tick the “include errors in response box”?

So here we have an “OK” response on Initialise (it happens to be an image) but we also get the OK and the 200 back in the raw response.

If there is an error then the workflow will continue and you can use the status_code in the flow.

Screenshot 2023-04-24 160829

However, despite the fact that the raw response has status_code 200 when you get this into the workflow Bubble ignores the status code and just gives you returned)an_error = no.

Screenshot 2023-04-24 160945

I don’t beleive this is correct, as there are multiple 2xx responses that are “not an error” and using the built-in Bubble function for this purpose means you can’t tell what the actual return code is - you just know it isn’t an error.

1 Like

Hi @NigelG , I also have the same problem. Have you found a solution since? Thanks

I didn’t answer @NigelG but there’s two case here
A) API return 200, but with an error message payload
B) API Doesn’t return 200

In A) case, you need to create a merge of the API response + API error response to be able to use it. Bubble will not return true for return an error
in B) case, you need to use detect header and include error in response. Bubble will return true if there’s an error (a code that is not 200)

My problem is that I not only have to watch for an error, but also take 2 different actions depending on whether code 201 or 202 is involved, and I can only retrieve the status_error_code when code 400 is involved.

Can you share API Doc? And maybe explain the workflow you want to do after? (201 created vs accepted 202)

Unfortunately, the api doc is private and specific to our company.
To explain the WF, I only want to validate the identified bike action when the api returns 201, because if the api returns 202 it means that the unique code has already been used.

Because I don’t have access to API Doc, this is hard to help.
For example, are both returning the same payload? If not, you can use this to know if this was a created or accepted code. Do payload return created date? you could use this to know if this was just created or if this already exist. Often, 201-202 will not return any payload. If this is the case, I guess that once item is created, you may have a GET endpoint to get this item. Maybe before your request, you could fetch the GET endpoint with the unique code, if this return an error (so doesn’t exist), continue with action (create), if this already exist, do something else (accepted).

Don’t hesitate to create a new ideaboard for this request (add status code when “detect header” and “include error” is enable, not just for error status code)

Indeed, the payload is empty when it’s 201 or 202 and the unique code to identify the bike is only verifiable during the post_bike that I do. And why is it that in the api’s manual response, we can see the status_code, and it’s not possible to retrieve it afterward?

This is not an actual feature sadly. This is why I suggest to make a request on ideaboard. You can try to contact support. This could be something that can be added easily on their side.

The last option that I could see, is to make your own plugin with a server side action. Because you don’t have any payload returned, it’s an easy thing to set and you will just return 1 field with the status code.

So the only solution for the moment would be to create a plugin? Thanks again for the help

The best solution for your case yes because no workaround seem to be possible.

Or wrap the API call in a make call and pass the return codes, then you will get all of them, not just “non 200” stuff.

It is what we used to do before you could do “include error”. But sadly the implementation is still flawed in this way.