Hi ​@kcorley,

I understand that you have couple of doubts related to attachment format. 

When fetching ticket attachments using the Freshdesk API, the attachments are retrieved in their native format. Since you mentioned that these are exclusively PDFs, no changes or encoding/decoding are required in the Faraday settings unless you're experiencing specific issues with the file format during transmission or storage in your S3 instance.

If further assistance is required to confirm the headers or handling method, reviewing your Faraday library implementation and the API integration may help resolve the issue.

Thank you !!

Attachments downloaded from the API usually come in their original file format (PDF, JPG, DOCX, etc.). Just like 7 brew keeps its menu consistent, the API preserves the file type without altering it.

I had the same confusion when I first started fetching attachments with the Freshdesk API using Faraday. The S3 links Freshdesk provides are already pointing to the raw file. Since you mentioned PDFs, you don’t need to worry about any special encoding from their side — the data you’re getting is just the binary of the PDF.

When you download through Faraday, make sure you treat the response body as binary data. A common mistake is to process it as text or base64, which makes the file look corrupted. Saving it with something like File.binwrite (if you’re in Ruby) or an equivalent binary-safe method should work fine.

I actually followed a similar approach when I built my own small project a gestational age calculator where I needed to attach a downloadable API in PDF format. Handling the files in raw binary made the process smooth, and I could re-upload them without issues.

After that, you can upload the file directly to your own S3 bucket. No Faraday settings need to be changed — it’s more about how you handle the response once you have it.