No 'Access-Control-Allow-Origin' header is present for ticket attachments


We have a need to retrieve the ticket attachment in our ticket details app so we can send it to a different page. We retrieve the ticket data by using the data methods. We do receive the data but when we actually do a GET request to the ticket attachment url we receive the error: No ‘Access-Control-Allow-Origin’ header is present

The strange thing is that this works for one FD account but not for two other accounts. Could it be that the CORS related response headers are different per hosting region? Or perhaps the older accounts run on an older configuration and that is why the response header is missing?

we retrieve the ticket data using:“ticket”)
an actual handler is implemented in the real code

then we get the attachment content using this script:

var xhr = new XMLHttpRequest();“GET”, attachment.attachment_url, true);
xhr.responseType = “blob”;
xhr.onload = function (e) {
var reader = new FileReader();
reader.onload = function (event) {
var res =;
let encodedItem = new Object(); =;
encodedItem.encodedString = res; =;
encodedItem.size = attachment.size;
if (count == ticketAttachment.length) {
window.appLocal.globallyEncoded = encodedArrayItem;

  var file = this.response;



Below the HTTP GET that is working correctly:

Response headers:
accept-ranges: bytes
access-control-allow-methods: GET
access-control-allow-origin: *
access-control-max-age: 3000
content-length: 35
content-type: text/plain
date: Wed, 14 Dec 2022 12:11:27 GMT
etag: “019aabeec752d0203e7d38b3274713d1”
last-modified: Tue, 13 Dec 2022 11:40:21 GMT
server: AmazonS3
via: 1.1 (CloudFront)
x-amz-cf-id: nvHT4TF7oD_eXf7x-hhAGgvaGvzs-D6qadwq5b8vpX9v8HLmGqhQvA==
x-amz-cf-pop: AMS1-C1
x-amz-server-side-encryption: AES256
x-amz-version-id: dO34kU._l3I1UsAyUMlrdFwMtUmu85Ht
x-cache: Miss from cloudfront

Below the request that is failing:

Response headers:

accept-ranges: bytes
content-length: 8623
content-type: image/png
date: Wed, 14 Dec 2022 11:02:39 GMT
etag: “ea691489b6f63ea40ed3cdde2bf7fe2f”
last-modified: Mon, 12 Dec 2022 14:39:05 GMT
server: AmazonS3
vary: Accept-Encoding
via: 1.1 (CloudFront)
x-amz-cf-id: blGXeIn9C0BEITxc-_TZazi1JsMWI_wWvAtxw8u0OsoSv0Ul8y3sQg==
x-amz-cf-pop: AMS1-P2
x-amz-replication-status: COMPLETED
x-amz-server-side-encryption: AES256
x-amz-version-id: QCL5msrTa5nc7QPxfBUbyRDaVZXBx9tf
x-cache: RefreshHit from cloudfront

Hey @j.couwenberg,

Thanks for getting this to our notice. Will DM you for some info.


This issue is still not resolved. Please share some tips on how to get the ticket attachment files from a Freshdesk sidebar app location.


Can I get some support on this please?
Anyone who can help?

Hi @j.couwenberg,

Thanks for your patience while we tried to figure out a solution.

As you have tried multiple approaches, this being a front-end app will result in a CORS error. And one way to overcome this is with a Request method or having an SMI in a Serverless component but due to restrictive content-type it is not possible with that.

Would using XMLHttpRequest() in SMI help?


Thank you for looking into this. If I would use the SMI then how would I get the ticket attachment data back to the ticket app? The response is strictly JSON so would I have to convert the ticket attachment to some sort of Base64 string and put that into the JSON? Are there restrictions to this?

With kind regards,

Hey @j.couwenberg,

The response is strictly JSON so would I have to convert the ticket attachment to some sort of Base64 string and put that into the JSON?

This would have payload restrictions.

I remember that you wanted to download the image so that you could send it to another API. Would downloading the image and sending it to the API in SMI help?


I was able to retrieve the attachments with a server component and pass it to the frontend component as a Base64 string. BUT, it seems there is another issue.
I can retrieve the ticket attachments if they were added manually in Freshdesk, but attachments of a ticket that was created because of an inbound mail CANNOT be retrieved. It then gives a HTTP 403.
There is a clear difference in the domain where the file is stored. See below

Attachment URL of ticket created via mail, this gives HTTP 403 when navigating to it:

Attachment URL of ticket that is created manually with manually added attachment, this does work:

Can you tell me why attachments that are imported via mail are not accessible?

Hi @j.couwenberg,

That’s great to know using SMI and returning data as Base64 worked. Can you give more details so that it would help others who are trying to build the same? Thanks! :tada:

I see the difference in links in terms of how and where they are being stored. Let me try to get you help in terms of that.


Do you have any update on research?

With kind regards,

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.