(I plan to submit a bug, but thought I’d post the question in the event anyone else was having this problem.)
I’m using a Workflow API to store attachments into an object in Bubble.
Here you can see the endpoint is expecting a value of type “attachment_file” which is of type “file”.
The expected behavior is that this attachment should then be stored inside of the Letter object as a file. Instead, it is being stored as a reference to the Zapier file and not the attachment. (Unfortunately, we don’t have access to any log files to see exactly what Bubble is importing.)
Now I know that the object being sent to Bubble is actually a file. I am also sending the same object to Dropbox and it’s being stored as a file, too. The images above shows the dropbox URL which is correct and I can see the files in Dropbox. Bubble, however, is not storing a file. Also, as seen below, the file_url is not pointing to Bubble’s amazon S3 storage, instead it is pointing to Zapier’s temporary file store. So it lokks like the Bubble API workflow is storing the file URL instead of the actual file object, then also using the attachments URL instead of just uploading the file and using the amazon S3 url.
So I decided to test this out by first importing a file via the API and then updating it via Bubble. In that first image above you see the data table with the file URL pointing to Zapier. After uploading a new file (clicking on the file and uploading a new one in the edit menu). You can now see the Amazon S3 url.
This isn’t a bug, this is by design (from the beginning). Every file in Bubble is represented as a URL. If you need to access the raw file, you have some ways to get the file from the URL (Blockspring custom blocks for instance) and then send the content to another service. We don’t support this out of the box, but you can do this.
Well look at how we can add this to Bubble, but no promise nor timeline.
Thanks for responding @emmanuel. I completely understand that correctly. Every major cloud storage uses links to represent files. Maybe I wasn’t clear in my explanation, but that is not the problem.
When I upload a file directly through Bubble using the File Upload component, the file is uploaded to Bubble and stored on your S3 instance.
When I do this using the API, this does not happen. When I upload through the API Bubble isn’t uploading the file and storing it on Bubble’s Amazon S3 instance. It is just only storing a text reference the temporary file URL Zapier is providing. The Bubble API should work just as if I were uploading it using the File Uploader but it’s not. It should grab the file from the URL then upload it to your S3 instance. The Zapier link is intended to only be a temp link so that my Bubble API can accept the files and store it permanently.
Does that help explain the problem I’m experiencing?
Thanks for the response.
Feel like I just took a huge punch in the stomach since this is a huge requirement for my app. I’m pulling in attachments from emails and this becomes a critical issue for me. Can I make a plea for this? I’m also going to try and think of another way around it. Maybe I’ll just feed the Dropbox URL to the file variable and see how that pans out.
This is a major infrastructure project, the enable streaming files to our servers, and not something we can do quickly unfortunately. We’ll talk about it internally, but don’t expect a quick turnaround on this, sadly.
Hi @emmanuel - Thanks for all your helpful responses on this forum, they have really helped me get up and running!
I just saw this below comment indicating the files can be uploaded via the API workflow which is something I am having trouble with now. Would you be able to point me to the reference material on how to do this?
@emmanuel Here is the Curl (truncated due to length). I have been struggling with this for a few days now. At the moment, I am still not able to save and use the file. Any help you might be able to offer would be greatly appreciated.
CURL:
{pdf_page_count=7.0, email_date=Saturday, October 7, 2017, pdf={filename=15ef4681b942a723.pdf, contents=JVBERi0xLjUKJb/3ov4KMTggMCBvYmoKPDwgL0xpbmVhcml6ZWQgMSAvTCAxODk0MTI4IC9IIFsgNzYxIDE2OSBdIC9PI…
I was not able to view the pdf or get the right filename using this object. It also didn’t show the s3 url like pdf objects usually do in this data viewer.
Thank you again for any advice and guidance you can provide!
It seems like you are not sending the data in the correct way with curl. It should be stringified JSON object and you should have a content-type as application/json. Can you share the whole request (truncating the pdf)?
Is it still the case that uploading files via the API is not supported?
I’m encountering the same issue that @saeed.t.richardson described five years ago - trying to move images from an AWS bucket into Bubble via Zapier but finding my original AWS link is getting stored in the image field in the Bubble back end as opposed to a link to the file on Bubble’s AWS bucket. That subsequently means that integrated Imgix processing doesn’t work, and the images are broken in the Wonderful Image Slider plugin, and both of those things are big problems for my use case.
It sounds like an alternative could be to get data into Bubble and then kick off an API workflow to lookup and import the images that way. Or just brace myself for manually uploading a few thousand images after getting the rest of the data moved via Zapier.
With some help from Matt at @RapidDev, I was able to make Zapier import all my data including images. The key is to configure an API workflow that makes changes to a thing’s image fields with a URL that leverages the saved to S3 action. Then in the Zap, after the step which creates the Bubble thing, add another step that sends the image URLs and the ID of the just created thing to the API workflow.
