How your files and your data are handled.
Find out where your files are stored, who can access account data and how downloads are protected. If you have security requirements for your shop, we can help you review them.
Last reviewed 25 August 2026. Reviewed at least once a year, and whenever something here changes.
Where FetchApp runs
The application and its database run on Amazon Web Services, partly directly and partly through Heroku. The production database sits in a United States region. Files are held in object storage and served through Cloudflare, and Backblaze is used for storage as well. Every one of those companies is named on the sub-processor page with what it does and what it can see. The sub-processor list →
Those providers hold their own certifications. Amazon’s data centre operations are accredited under ISO 27001, SOC 1, SOC 2, PCI Level 1 and other schemes, and Backblaze publishes its own controls in its data processing agreement. Those are the providers’ certifications and cover their infrastructure. FetchApp itself does not hold these certifications.
Where your files live, and how they are served
Each uploaded file is stored separately from the application. There is one stored copy of the file, rather than a new copy for each order.
When a buyer opens a download link, FetchApp creates a signed link that allows access to that file for a limited time. The file is served from a FetchApp address. Knowing the storage location alone does not give someone access without a signed link.
Delivery links are yours to control. You can expire them after a set time, after a number of downloads, or both. Permanent links exist for cases that need them, and those ignore both limits. Use them only when you want ongoing access. Download limits and expiry, in detail →
FetchApp does not lock, watermark or wrap your files. Your buyer downloads the file you uploaded, without changes to its contents.
Larger accounts can use their own file storage and have FetchApp deliver from it, keeping the files in storage they control. Storage options →
Encryption during transfer
Connections to FetchApp use TLS encryption. This protects data during transfer when you use your admin or the API, and when buyers open delivery pages or download files.
Encryption of stored data, also called encryption at rest, has not yet been confirmed. Confirming and documenting it is planned work.
The Shopify connection can serve order lookups and downloads from your storefront’s address. These requests pass through Shopify’s app proxy, which FetchApp checks for a valid Shopify signature before serving them. How the Shopify integration works →
Who can access your data
Access to production systems and to customer data is limited to the people who need it to run the service, and it is removed when someone no longer needs it. Deploying software and reaching production systems are restricted the same way.
Support can see your account, your products, your orders and what happened to a specific delivery, so they can help with delivery questions. Support cannot see your card number, and cannot take a payment from you over email. If someone claiming to be FetchApp asks you for card details, that is not us. What support can and cannot do →
Card data
When we bill you directly, your card is handled by Braintree, a PayPal company, and FetchApp does not store the number. What we keep is Braintree’s reference to the card and the last digits, which is enough to take a renewal and enough for support to tell one card from another.
If you installed FetchApp from the Shopify App Store, Shopify bills you through your Shopify account and no card details reach us at all.
The payment provider is responsible for card handling. Its compliance certifications apply to that provider and are not FetchApp certifications.
Controls that are not currently available
FetchApp does not hold a SOC 2 report. There is no published schedule for penetration testing, which checks for security weaknesses. Single sign-on is not available, and additional account security options are planned but not yet available. There is no documented incident-response procedure with a notification timeline, and no status page.
If your organisation requires any of these, contact us before signing up. We will help you check FetchApp against your requirements. Reliability, and what we measure →
Found a vulnerability?
Email [email protected] with “security” in the subject line and it will reach the people who build FetchApp. Tell us what you found, how to reproduce it, and how you would like to be credited.
We will confirm we have received it, tell you what we think it is, and tell you when it is fixed. There is no bounty programme, and we do not negotiate one.
We will not pursue legal action against anyone who reports a problem in good faith and gives us a chance to fix it first, subject to the conditions in our terms. These include testing only your own account, leaving other customers’ data alone and not making the report conditional on payment. Read the full conditions before testing. The safe-harbour clause →
If a report affects live deliveries, say so in the subject line, because it changes the order things get read in.
Need this in a questionnaire?
Send the questions to [email protected] and we will answer them directly. A data processing agreement naming your entity is available on request.