It seems that key names that include an underscore are an issue. For example, I have three keys that include underscores: pub_key, is_teacher, and full_name. These appear incorrectly when the API is called.
Furthermore, I tested another backend workflow that responds with JSON data in Python and the parameter names are all sorts of messed up.
For example, if I have a data field named “body” that is a “text” type on the custom data type “question”, then the JSON output names the “body” field as “questionbody_text”. Is this a bug or the intended behavior??? I can’t change the webhook for the third party and without consistent and accurate parameter names in the JSON response when using the “Return data from API” action, my backend webhook is broken.
If you are using Display fields, then the field names will match a sanitized version of the Display name for your fields. - Otherwise, they will be a bubble-generated ID resembling “fieldname_fieldtype”
As always, you offer great information hidden deep in the documentation. However, it seems that Bubble is still not properly setting the key names for my response data. I am returning text and boolean data, nothing related to data fields. The webhook requires very specific parameter names in the response, and Bubble seems to have an issue handling names with underscores. I can’t get this response to work properly no matter what changes I make.
I added drawings to my screenshots to highlight the issue.
I have that setting enabled, and I get the expected result when I return a response. For instance, I exposed an endpoint which stores a file, and when I send the response like so…
Ah, ok, so maybe the issue is that Bubble sends the response formatted in a very specific way. Hmm, not sure that can be changed.
EDIT
You can return a plain text and get the response body to be exactly what you want…
{
"my_response": true
}
However, the problem will be that the content-type header will be incorrect for the receiving end. Might be worth a try though. Perhaps it will ignore that header and interpret it as JSON anyway.
It seems that Bubble includes the “status” in the JSON response but the webhook only wants the response. I hope there is some way to fix this or at least be able to use the plain text with a JSON content header. This seems like a weak point in the Bubble platform.
Or at least be able to specify the content-type. I can imagine scenarios where one might want to return XML or some other type as well. Seems like a good feature request.
One work-around would be to implement what I call a “proxy” endpoint using a service like Integromat or Zapier (for a no-code approach). That service would call your Bubble endpoint, transform the data, and then send the response to the API you’re using (which of course would be configured to point to the Zapier/Integromat endpoint instead of your Bubble endpoint).
In fact, I now remember that I did exactly that for a job posting API quite some time ago that needed the response in XML format.
Thank you Steve. I will try to find a workaround. It’s becoming very frustrating to develop in Bubble with the consistent bugs and “almost right” features. It seems like they just missed the mark on many of these features and just moved on. I’m hoping they focus their energy on considering building more versatile features rather than a bunch of moderately useful yet limited features.
EDIT:
Unfortunately, Zapier does not seem to allow for custom webhook responses -_- This is very very frustrating.
EDIT 2:
It’s starting to feel like Bubble is not worth the trouble anymore.
EDIT 3:
I was able to get my integration set up via Integromat. However, to me this isn’t a solution. I came to bubble to build my company on their platform, not to Frankenstein together hacks. The return data from API Action needs more flexibility. It’s the only response action for Workflows outside bubble and it is currently unacceptably rudimentary.
