Feature Request: 'Return Data from API' More Content Type Options

Currently, return data from API can only return application/json (the default) or text/plain (if plain text is selected.)

The problem with this is that some APIs do not accept either of these return types and/or only accept one and the resulting behavior isn’t desirable.

For example, for my use case is I’m receiving a POST from Twilio for a new incoming text message. The Twilio API does not accept a application/json response and Twilio interprets a plain/text response as a auto-reply and sends a text back to the original sender with the contents of the plain text. I don’t want to trigger an auto-reply, so I’m just stuck.

TWO POSSIBLE SOLUTIONS

Solution #1: Add a “custom” option that would allow the user to type in a custom Content-Type header, and type anything they want into the body of the response. This is essentially what text/plain already is, I’m just suggesting that the user be able to type in their own header rather than it being locked to plain/text. Mockup:

Solution #2: Add text/html as an option. Mockup:

Either of these solves my problem, and while I think solution #1 would solve all use cases ever, solution #2 is likely to cover 99% of use cases as opposed to maybe the 89% of use cases covered by the current options.

8 Likes

Bump + 1

1 Like

@josh can we get this?

Vote for this!

As a solution, you can use TwiML Bins:
https://www.twilio.com/docs/serverless/twiml-bins

But, yeah, it’s much easier and faster if Bubble provides that option. Would love to see that feature.

This would be awesome!

1 Like

Not sure how this would work. I’m sending a webhook straight to my Bubble app. Are you saying route the webhook to the bins first and then make a second call from the bin?

Interesting challenge.

I’m way out of my depth, mind if I brain-fart? Doesn’t the API builder have an option to redirect the call to another page? Could you do something with that? Hmmm :thinking: any Bubble page will add a bunch of extra stuff to the HTML so you won’t be able to craft a proper Twillio ML document.

I’ve attempted that and it doesn’t solve this issue unfortunately.

The core of it is that plain/text and application/json are not the only two content-types that are needed to work with modern APIs, so it’s a serious problem that Bubble has us locked down to only these two options for API responses.

You can always find workarounds, but the point is that this isn’t something we should have to have a workaround for. This is basic API functionality.

1 Like

yup

the following one is for Calls

but as I know you can do the same thing for SMS as well

Hey everyone! Just shipped the ability to specify a custom content-type on the “Return data from API” action. Learn more: Allowing custom content-types on “Return data from API”

1 Like