_Last updated: May 27, 2026._
PartyKit Uploads ("the app", "we", "us") is operated by Tumbly Haus Creative for use with Shopify stores. This document explains what data we collect, how we use it, and your choices.
Who this affects
- ›Merchants who install PartyKit Uploads on a Shopify store.
- ›End customers who upload files via the app on a merchant's storefront.
Data we collect from merchants
When a merchant installs the app, Shopify grants us access to specific scopes. We use only what's needed:
| Scope | Why we need it |
|---|---|
read_products | List products in the admin so merchants can configure per-product upload rules |
write_files | Upload customer-submitted files to the merchant's Shopify Files library (default storage backend) |
read_orders | Link uploaded files to the orders they were attached to so merchants can fulfill them |
read_customers | Display "uploaded by [customer name]" in the merchant's admin file browser |
We store a single row per installed shop containing: shop domain, install timestamp, chosen storage backend, and default upload rules.
Data we collect from end customers
When a customer uploads a file on a merchant's storefront, we store:
- ›The file itself (in the merchant's chosen storage backend — Shopify Files by default).
- ›File metadata: filename, MIME type, size, upload timestamp.
- ›The cart token (a temporary identifier) so we can later link the upload to the resulting order.
- ›The product GID, variant GID, and (after checkout) the order GID and line item GID.
We do not collect customer names, emails, IP addresses, geolocation, or device identifiers from the storefront block.
Cookies and tracking
The storefront block does not set cookies and does not load any third-party scripts.
The embedded admin app uses Shopify's session token system (no third-party cookies).
Where data is stored
- ›Files: in the merchant's chosen backend (Shopify Files, S3, R2, Google Drive, or Dropbox). Files in Shopify Files belong to the merchant and remain after uninstall.
- ›App database (serverless Postgres, hosted on Neon in a US region): metadata, configuration, upload records.
How uploaded files are accessed
Customer-uploaded files get a public URL that's attached to the cart line and the resulting order as a line-item property. This URL is what allows the merchant to fulfill the order — opening it shows the artwork the customer wants printed.
Important access model:
- ›Shopify Files: The URL is an unauthenticated, permanent CDN link. Anyone who has the URL (the customer who uploaded it, the merchant, anyone the merchant forwards the order to, the customer-support agent who opens a screenshot of the cart, etc.) can view the file indefinitely. There is no expiry.
- ›S3 / R2: Same model unless the merchant has configured their bucket with signed-URL access. The URL is generated by the storage backend at upload time.
- ›Google Drive / Dropbox: The URL is a "share link" — unlisted but not access-controlled. Anyone with the URL can view.
This is the intentional access model — fulfillment is asynchronous and the merchant needs durable access to the file to print it. But customers and merchants should understand that any URL forwarded outside the original cart/order context is a permanent read-access grant.
Merchants requiring stricter access control should use a BYO S3/R2 bucket with signed-URL configuration, or download the file out-of-band after order completion and delete the public copy.
Content moderation
Merchants can enable optional AI content moderation. When it's on, uploaded images are screened for explicit (NSFW) content in the end customer's own browser, before anything leaves their device — using an on-device machine-learning model (NSFWJS).
- ›Images the filter blocks are rejected on the customer's device and are never transmitted to us, to the merchant, or to any storage backend — they don't reach our servers, our database, or any uploads queue.
- ›We do not send images to any third-party moderation service for this check; it runs entirely client-side.
- ›Merchants control whether moderation is on, the sensitivity threshold, and whether flagged uploads are blocked outright or held for manual review — in the app's Settings.
Data retention
- ›While installed: data is retained for the life of the installation.
- ›On uninstall: app data is cascade-deleted by the
app/uninstalledwebhook. Files in the merchant's storage backend are left in place (they belong to the merchant). - ›On
shop/redact(48 hours after uninstall): any remaining data is purged. - ›On
customers/redact: all uploads and metadata associated with that customer ID are deleted.
Subprocessors
- ›Shopify, Inc. — app hosting platform, payment processing
- ›Vercel, Inc. — application hosting (US/EU regions)
- ›Neon, Inc. — database hosting (serverless Postgres)
Your rights
Merchants can request a copy of their data, correction of inaccuracies, or full deletion by emailing support@tumblyhaus.com.
End customers should direct data requests to the merchant whose store they uploaded to; the merchant can then forward via the customers/data_request webhook flow.
Changes to this policy
We'll update the "Last updated" date above and post material changes to our public changelog at <https://partykit-uploads.tumblyhaus.com/changelog>. For material changes that affect what data we collect or share, we'll also notify installed merchants by email at least 30 days before the change takes effect.
Contact
support@tumblyhaus.com