We’ve just added a new generic “file” data type to the API Connector plugin, which will allow you to get any sort of file from an API.
20 Likes
Cool - Does this support sending photos without needed to base64 encode it?
1 Like
It should! This will fetch any sort of file without altering it in any way.
Can it be used to POST invoices?
Wonderful! How did you know I was exactly needing this today?! 
Keep going guys!
Thanks
Mario
This is just used for fetching files.
1 Like
It would be great to retrieve Headers, in particular Content-Disposition, so to extract the filename, for example.
Also, save to S3 and base64 conversion option would enable greater integration scenarios. I’m currently managing files outside Bubble because of these limitations.
Thanks
Mario
This might prove handy… thx.
The file option does save to s3, returning a link to the uploaded file. I’ll work on making this clearer.
Regarding headers and base64 conversion, thanks for the input. We can probably make this happen!
Hey @marca, can I ask a somewhat weird question? If one is creating an API to send back a FILE (in addition to other things) in response to a POST request … is there a way to do that with JSON? The question is: WHAT is Bubble looking for that makes it interpret a JSON object coming back as a file?
(I get that the feature you’ve enabled here is a generic GET type operation, but my question is related.)
I’ve built several little microservices that shoot stuff back to Bubble in response to POSTs. However, I have a need for one that shoots back a block of text (works fine), a FILE representation of that text (with filename, etc.), and some other data. I just cannot figure out how to get Bubble to interpret the FILE part as a file.
The difficulty being: I’m building my microservices in Webtask.io, which is Node. Node doesn’t have the same File() constructor as plain-old-Javascript. But the “file” I’m making is literally just a text file (my microservice composes its text and it’s completely stored in memory).
What would I send back to Bubble to make the Bubble API connector see it as a File? I’ve tried all sorts of things, like just sending back the bits base64 encoded, sending a JSON that looks like the one described in https://bubble.io/reference#API.sending_data under “Files and Images”, etc.
It would be EXTREMELY handy if there were some thing I could construct (without having to resort to file streams or whatnot) that would tell Bubble, “Hey, this JSON represents a file. Here’s its data, suggested filename, and MIME type. It’s all there – just save this to s3 and return me that URL.”
I guess I’m just missing something… But it’s weird that the API connector “initialize call” feature allows one to tell Bubble “interpret this part of the JSON as being type ‘file’”, but nothing seems to be accepted…
Any help you might be able to offer?
Best regards,
Keith
If you select the file option, Bubble will dump everything–JSON or otherwise–into a file, and return an s3 link. Is this what you’re trying to do?
Hi marca: Yeah, that’s pretty much what I’m trying to do, but I find it doesn’t work that way.
When you say “everything”, you mean the entire response? (i.e., even if my response returns a bunch of different keys and I select FILE as the type for only one of them…
Here’s an example of what my API returns and how Bubble sees it (defaults):
OK WAIT @marca … I think I get it now. Did not realize there was a data type FILE option on POST API calls now. That’ll do what I want. I get it now…
Your response helped me did around the interface and understand it a bit more. 
… though it would be cool if a response could pass back multiple keys including a file key (which I think IS supported… I just can’t figure out how to make it work right from Node…)…
OK, so I’ve successfully used this new feature to create an API that builds iCalendar files (.ics files, type text/calendar) and returns them to Bubble where they are automagically stored.
This is great, but I’ve run into a problem. What I need to DO with them is serve them up (the file ITSELF, rather than a page) when an external system (or user) hits a certain URL.
I know what you’re going to say: "Well, just tell the external system or user than the URL to hit is the URL of the file as saved in s3.)
That solution would work fine, except that these files change frequently. And there seems to be no capability to save a NEW version of the file to the SAME URL in s3 as the previous version of the file. So I can’t seem to have a persistent, reliable URL / URI that points to a file saved in this way.
I’ve tried various workarounds such as:
-
Creating a page with a HTML header a http-equiv refresh directive. While this works great for human with a browser, external systems expecting a file do not like it.
-
Creating a page that executes a similar redirect-like action in JavaScript (window.location.href and window.location.replace). Again, works fine for a human with a JS-enable browser, but external systems do not like it.
-
Toying around with the Data API to retrieve the file(s) that way. However, there seems to be no way to have a GET call to Bubble’s API that can run WITHOUT AUTHENTICATION. (And if there IS, it’s not clear to me that you can serve back a file – seems like what comes back is always JSON.)
So, the question is: Is there a way to accomplish what I’m trying to do? It SEEMs like what I need is a way in Bubble to create server-level redirects that the system could change whenever s3 URL changes due to the file having been modified. (Like “myapp(dot)com/[something]” points to “This_listing’s_ical_file’s_file’s_URL”)
Is that possible? Could that be implemented?
Thanks!
Keith
2 Likes
@keith, let me look into this and get back to you in the morning.
I realize this is a second step, but could you create an API that could provide your external system with the up-to-date URL?
1 Like
Thanks @marca, while that’s possible it seems odd to call an api to callback to Bubble simply to serve a file (and slow).
I’m not entirely sure actually why other apps that expect a .ics file balk at the page level redirect, but they don’t like it. Could be as simple as content type header or something but I’ve not had a chance to muck around with that.
I also feel like there may be a bug in the File receipt as data feature. To get my file, I create a new thing (if it does not exist) or change a thing I’ve called “icsFile” which has two fields: File (type file) and Listing (the listing to which the .ics file relates). File comes from “get data from an api” call.
When first created, the File field correctly points to the s3 file. However, a subsequent use of Make changes to a thing (where again the File field is populated via “get data from an api”) causes a new file to be created and saved to s3, but the pointer in File continues to point to the original file (it does not change).
Workaround for that issue seems to be Create a New Thing (of icsFile type) and delete the previous one.
You should email support with an example of what you’re trying to do. If we can’t come up with an adequate workaround, we should be able to add this feature.
1 Like
Are the GET parameters to the API the same on the second call? If so, Bubble won’t make the call, and instead serves the cached result of the first call. You can workaround it by making the parameters or headers or url different.
Well, yeah parms are the same, but it’s a POST. Seems like a bug to me… the file ref should def change (because, expected behavior).
To wit, the call “returns a link to the file”. If I set File field to be the result of the API as data, File field should change. (It works this way on JSON type POSTs…)