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:
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.
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?
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 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.