Legal · Updated July 28, 2026
Privacy Notice
How ImportReady handles account, payment, support, and optional operational data while keeping spreadsheet contents on your device.
1. Scope
This notice describes personal data handled when you visit ImportReady, create an account, purchase or activate a licence, request support, or opt in to operational telemetry.
ImportReady is designed so that spreadsheet contents are processed in your browser. CSV and workbook bytes, cell values, repaired rows, and generated exports are not intentionally transmitted to our servers.
2. Data we handle
Account data can include your email address, display name, authentication identifiers, preferences, and licence entitlement. Once paid checkout is activated, transaction data can include order reference, amount, currency, status, and Stripe identifiers. Complete payment-card details will be entered in Stripe-hosted Checkout and handled by Stripe, not ImportReady.
In the current pre-launch build, the browser does not send processing telemetry or create shared reports, and Stripe Checkout is not live. Those schema-backed capabilities require separate production implementation and consent controls before use.
- Support data you choose to send, including messages and contact details.
- Security and access data such as session cookies, timestamps, IP-derived service logs, and abuse signals.
- Optional coarse telemetry such as destination, file type, size bucket, row count, duration, outcome, app version, and machine-readable error code.
- Aggregate shared-report counts when you explicitly create an expiring share link.
3. Local file processing
File parsing, validation, mapping, repair, preview, and export are intended to execute locally. Mapping templates are stored in browser IndexedDB. Selected static assets and an offline fallback may be cached, but spreadsheet contents are excluded from the service-worker cache.
You control the files you select and the exports you download. Clearing browser storage can remove local templates and recent-file metadata. The current service worker provides an offline fallback and static-asset caching; it does not promise that a fresh offline navigation will reopen the complete workspace.
4. Why we use personal data
We use account and entitlement data to provide the service, authenticate users, activate licences, enforce plan limits, prevent abuse, respond to support, deliver receipts and keys, maintain security, and comply with applicable accounting and legal duties.
Campaign and winback messages should be sent only where permitted and according to your communication preferences. You can opt out of non-essential marketing messages without losing transactional account email.
5. Service providers and transfers
The planned service boundary uses Vercel for application hosting, Supabase for authentication and account data, Resend for email delivery, and Stripe-hosted Checkout for payment processing. Stripe is selected, but checkout is not live in the current pre-launch build. These providers process data under their own security and contractual commitments.
Before launch, publish the final subprocessor list, processing locations, and transfer safeguards that apply to the operating entity and customer region.
6. Retention
Data should be kept only as long as necessary for the purpose collected. Account and licence records normally remain while an account is active; statutory transaction records may be retained longer; support and optional telemetry should use documented, limited retention schedules.
The production policy must state exact periods after legal, tax, fraud-prevention, and support requirements are confirmed.
7. Your choices and rights
Depending on your location, you may have rights to access, correct, delete, restrict, object to, or export personal data, and to withdraw consent. Requests will require reasonable identity verification.
You can decline optional telemetry. You can also delete local templates through the application or by clearing site storage in your browser.
8. Security
The production architecture is designed around least-privilege access, row-level database policies, verified server-side identity, hashed licence and share tokens, server-only service credentials, secure transport, audited privileged actions, and input validation. The current admin interface is read-only and displays live account, billing, and consented aggregate records; production admin mutations and telemetry collection are not connected.
No system is perfectly secure. Report suspected vulnerabilities through the contact page and do not include sensitive spreadsheet contents in the report.
9. Contact and changes
Material changes will be dated on this page. Before production launch, this section must identify the legal controller, mailing address, privacy contact, and any required representative or data-protection officer.