We can not reproduce your issue on our side, unfortunately. Can you please add the support@zeroqode.com as a collaborator of your app? It is possible to add the support account as a collaborator even if your subscription plan is a Hobby.
I presume you have set something wrong on your side (bucket policy security or plugin), we need to verify the plugin work within your app, if you don’t mind.
Also, would you kindly share the screenshots of your bucket and plugin settings? 
Regards,
Kate
Hello,
I am experiencing the same issue. The plugin uploader give me zero code issue but the NO GUI uploader is working so it can’t be a problem of settings.
Did you find any solution to this problem ?
Also there is an issue when using multiple NO GUI uploader in the same page, when you put multiple actions in the workflow for ‘a NO GUI ulpoad start’ and ‘NO GUI upload end’, only the first ‘NO GUI uploader’ actions is done for all other ‘NO GUI uploader’
Regards,
Regis
Hello @regis.amon. Thanks for reaching out.
Please accept my apologies for the late reply.
This issue is typically happening when the bucket settings and plugin are differing (even for a bit). Typos, excess symbols, incorrect mismatching address - this can cause the issue. A common case is when the bucket is in one region, and the application is in another.
Please make sure you have checked your bucket settings very carefully and followed our documentation.
These forum threads should be helpful:
If you have checked everything carefully - please share the console screenshot with the error you get. There is no issue with the plugin on our side, as I can see.
I hope it helps. 
Hello Kate,
Thanks for your answer and the indications but it is not that, I double checked everything.
The plugin is set up like in the doc :
Also if the plugin was not well set up, how could you explain that the noGUI is working (files are present in the S3 bucket) like in the gif below and the GUI File uploader respond with zero code. Please don’t tell me it’s a AWS set up problem, it really seems the error is in your plugin.
Regards
Regis
@regis.amon,
Apologies for the late answer.
As per the fact, there is no issue observed with the GUI/noGUI uploader elements on the plugin demo page, we presume that the issue on your side can be probably caused by the mistake in the Bucket setup. Any slight mistake like a typo or access symbol can be the reason for the trouble.
Anyway, let me please double-check once more this case with our devs. Thank you for your patience.
Regards,
Hello, @regis.amon.
We have re-checked the plugin again on our side and we have not encountered any issues. As per this fact, we are sure that our AWS bucked setup/plugin setup is correct, and If you follow our docs and re-check your setup carefully - the no GUI/GUI uploader will be workable on your side as well.
Also, you may see from the previous user’s replies, that even the typo in your AWS bucket settings can affect the plugin work:
If you kindly provide us with access to your app, where the plugin is installed, we can test it using our AWS Keys to make sure the plugin works OK. You can add our support@zeroqode.com email as a collaborator of your app.
I rely on your understanding
Regards,
@regis.amon @kate @mkrandel @tjc4 @kieran Did anybody get the GUI version working? I have the same issue as they all had: “No GUI Uploader” works fine and uploads to S3 bucket, but the “GUI” uploader returns the 0 code error message.
Hello, @chris.brenden
Thanks for reporting the issue.
If you carefully followed the documentation for the plugin and this issue appeared, the reason is the wrong JSON settings. Please copy and paste the following codes into their respective blocks:
Bucket policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "YOUR_ARN_HERE/*",
"Condition": {
"StringLike": {
"aws:Referer": "YOUR_DOMAIN_HERE/*"
}
}
},
{
"Sid": "AddPerm2",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "YOUR_ARN_HERE/*"
}
]
}
ACL
CORS
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET",
"PUT",
"DELETE",
"POST"
],
"AllowedOrigins": [
"YOUR_DOMAIN_HERE"
],
"ExposeHeaders": [
"ETag"
],
"MaxAgeSeconds": 30000
}
]
Save the setups, then give it a try again, please.
Best regards,
Thank you for the quick response, Ecaterina. Actually, I got it to work before your response, as what you’ve listed is what I ended up with, haha.
For those that have similar problems that I had: although I did not pinpoint it exactly, as I changed many things at once before testing functionality, I believe my initial mistake was that I did not change the permissions policy on the unauthenticated role in IAM. I only did the authenticated role.
Hello, @chris.brenden
Happy to hear that you were able to fix it all by yourself.
In case of any additional questions will appear - please let me know. We will be happy to assist you with them.
Best regards
Just a little PSA of my experience configuring this plugin. Like others in this thread, I was receiving the “Server Responded with 0 Code” when attempting to upload images, yet when using the No GUI functionality it was working. As was advised to others previously, I went through the syntax of the AWS permissions attempting to find some minor and/obscure typing error. I did this for hours presuming it had to be a syntax mistake on my part. Keeping the story short… there appears to be some issue between the plugin and the bucket. My original bucket naming structure used a dot separator nomenclature. For example, “clientname.appname.descriptor”. However, once I created a bucket using a non-dot separator it was working immediately. I tried with both underscores “clientname_appname_descriptor” and hyphens “clientname-appname-descriptor” and both worked. I created another bucket that used dots in the name and reproduced the same Server Responded with 0 Code errors. Although S3 supports using dots in the bucket name, something in the plugin (v1.86.0) did not like it. Again, it’s working great simply using hyphens or underscores.
Hello, @jlexer
Thanks for your valuable comments.
Firstly, plese allow me to recommend you this AWS documentation, which will be useful for bucket naming:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
So, sometimes the incorrect bucket name could reproduce the issue with the server response. However, I’m happy to hear that you have figured out this situation.
Best regards,