Forum Documentation Showcase Pricing Learn more

[New Feature] File option on API Connector plugin


@keith Yes sounds like a bug then. To help determine the extent of the problem …
Experiment 1 - alter the params on the second call
Experiment 2 - serve different content on the second call


Hi @marca, any way we could also have an API call to POST File? Especially for images? Base64 adds Overhead and it would be nice to be able to POST an image / file once uploaded via API.

Thank you


Hey @marca, I did pass this along to Support. Thanks for your assistance.

My current workaround is to use Rebrandly as a “redirect” mechanism. (Give listing a Rebrandly URL which points directly to the .ics file URL in s3. Update the destination of the Rebrandly link when the file changes.) … but it would just be far easier if we could simply serve up files directly from Bubble (without loading a page, which is the source of this issue, fundamentally).

Best regards,


gilles, I believe you can already do this, if I am not mistaken. See my attachment. This is geared toward the Wrike Api (a project management software) but I believe it should work for any API. They needed a Base64 encoded image as well.

Set the body type to “Form-data” then the parameter gives you the option to add a value that is an image. Check off Send file and it should work! Note the content type I have in my header - octet-stream. That’s important as well. The other two items (X-File-Name and X-requested) I don’t think are important…

P.S. If you want to be able to dynamically add an image, uncheck Private.

P.S.S. I named my parameter key “data-binary” since that’s what Wrike recommended.


Thx - you noted “they needed a Base64 encoded as well” - does this procedure/steps automatically POST encoded Base64? By default, I’ll POST my image via base64, but if there’s a way to not send it in base64 format, I would prefer it to be that. Base64 adds extra overhead ( ~30%) vs just sending the raw image. Trying to save my customers time when they’re uploading from their mobile devices.

Thank you -


Update: support doesn’t quite grasp what I’m going on about. Sigh.

In case it’s not clear: Sometimes, you just need the URL to a static object like a file (be it an image, pdf, ics or whatever mime type you might think of). But in the current bubble environment, if you rely on external APIs to generate such things (as one must), you will NEVER have a persistent URL for such a thing.

But even that is somewhat beside the point as you can’t at present build a true redirection tool. You can redirect a user’s browser, but you can’t do (in a dynamic, programmatic, non-user-authenticated, scalable way) true redirects or file serves connected to your domain.

Like I can’t create alias:


Which resolves in all cases to “an actual jpeg that resides at some other URI”.


Sorry for not fully understanding your feature request. Our response was based on your preferred workaround methods. A test page / workflow with an example that shows the current limitation will be very helpful to explore what features would have to be added to support your exact use case.


Hi @neerja,

I can provide a simplified(ish) example of why this issue arises and why workarounds do not seem to exist. Can create a video that explains.

Best Regards,


I believe so - However, I don’t believe there is an option to not send it by base64. I don’t have enough experience unfortunately with the matter. I’m sure there is a way to do it, but as with most advanced topics in Bubble, the solutions are sometimes way more complicated than expected :confused: