How do I return XML via an API workflow?

I see how to return JSON or a Plain Text from an API workflow, but is there anyway to send XML?

I’m working with Twilio programmable SMS and they only accept an XML response.

If you use plain text, but within that plain text field in bubble, have valid xml in it, does that satisfy Twillios needs for it to be in XML? Or does Twillio still see it as just text?

Unfortunately Twilio sees it as just text which results in it sending the XML as a text message back to the original sender (not good).

If I leave the plain text empty then bubble runs into a “temporary error” and the workflow fails entirely.

According to their documentation, I should be sending <Response></Response> with a Content-Type header of “text/xml”.

I guess my next question is… for your use case to work, does it have to be a response, or can it be another API call back to Twillio? Becuase if so, you can use the API connector in the second step of the workflow to send it back, and that supports XML. It’s not clean, but it could be a work around for you depending on what you’re doing in Twillio.

If not, the only thing I can see that would give you anymore insight on how to do this is to enable “capture response headers” on your API workflow… see if there’s any data of value in there coming from Twillio.

That won’t work unfortunately. The issue is not that the JSON response doesn’t work (the workflow runs and my app operates as desired), but rather that Twilio is logging a “Invalid Content-Type” error in their debugger for every incoming text message.

Since we’re working with a VOIP app, I need the debugger to alert me to when there’s a real problem. If it’s always full of unimportant errors then I’m likely to miss something important (like I did today resulting in 2 hours of my users not being able to receive incoming calls).

I’m just trying to stop these errors from accumulating for no reason. Might try to contact Twilio support and see if they can somehow filter that out from my debugger.

Did you ever find a solution for this? I have the exact same problem. I was thinking that I could possibly redirect to a page that returns a XML file. Or if that won’t work, maybe have Twilio point to something like Integromat that then calls the Bubble endpoint.

I just put up with it. The integromat would work and solve it I believe though, but that’s such a pain.

Well that’s a pain, and in my case the Twillio error message is causing problems for the Bubble API workflow. Will post if I find a better solution!

1 Like

The return data to API function needs to have headers as well as parameters. Would solve many problems and limitations.


I ended up using Integromat, which is annoying because now I’m paying for a service to simply return a 200 response in XML

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