privacy-notice

Kitchen Toolkit — Privacy Notice [source: docs/legal/privacy-notice.md]

Last updated: 2026-03-22 [source: docs/legal/privacy-notice.md]

This Privacy Notice explains how Kitchen Toolkit (“KT”) collects, uses, and protects your data. [source: docs/legal/privacy-notice.md]

## Data we collect
- Device and manual log submissions include restaurant/tenant identifiers, deviceId, type, server and local timestamps, client-provided timezone, IP address, HMAC signature, and the log payload you send. [source: pages/api/uploadLog.js]
- Equipment telemetry and alert state updates store equipment identifiers, tenant/restaurant IDs, temperature readings, thresholds, node identifiers, and notification targets needed to deliver alerts. [source: pages/api/uploadEquipmentLog.js]
- Push notification subscriptions and related metadata include subscription endpoints/keys, tenant IDs, device IDs, and user-agent details used to deliver operational notifications and to prune abandoned subscriptions. [source: pages/api/push/subscribe.js][source: lib/push/subscriptions.js]
- Browser-side state may store local export preferences, device IDs/secrets, queued offline logs, cached restaurant bundles, push metadata, and short-lived session/access cookies required to operate the crew app and protect non-default tenant content. [source: pages/index.js][source: public/js/restaurantLoader.js][source: public/sw.js][source: lib/auth/session.js][source: lib/auth/contentAccess.js]
- Tenant profile data (business name, address, contact email/phone, timezone, alerting preferences) saved through the admin console. [source: lib/tenant/env.js][source: pages/admin/settings.js]
- Tenant-specific environment variables (SMTP credentials, webhook URLs, notification emails, storage KV URL/token, billing identifiers, retention overrides) encrypted at rest. [source: lib/tenant/env.js][source: pages/api/getTenantEnv.js]
- Billing metadata exchanged with Stripe checkout and webhooks (tenantId, plan, autoRenew flag, Stripe customer/subscription IDs, billing status, service cutoff reason) to administer subscriptions. [source: pages/api/billing/checkout.js][source: pages/api/billing/webhook.js][source: lib/billing/stripe.js]
- Hosting metadata: Kitchen Toolkit runs from a private GitHub repository deployed to Vercel, with default KV storage in Upstash (AWS N. Virginia `us-east-1`) unless you provide your own `storage_kv_url`. [source: docs/reference/data-and-privacy.md][source: lib/tenant/env.js][source: pages/admin/settings.js]
- Builder and restaurant content may be written into Git-backed tenant bundle folders and mirrored precache folders when published from the Builder. Active files can later be removed, but repository history may still retain prior versions. [source: pages/api/buildRestaurant.js][source: pages/api/deleteRestaurant.js]
- Password reset and initial setup token metadata (per-tenant token IDs, issued timestamps, tenant ID) stored in KV for up to 15 minutes to process self-service resets and first-time admin setup. [source: pages/api/tenant/requestPasswordReset.js][source: pages/api/tenant/resetPassword.js][source: pages/api/tenant/signup.js]
- Alert, equipment, and log exports assembled for administrators via `/api/exportTenantData`. [source: pages/api/exportTenantData.js]
- If you use the public Help desk, KT processes the submitted question text, attachment metadata/content, provider/runtime metadata, and temporary support cache/session identifiers; image attachments may be published to short-lived support URLs for provider-side visual analysis and support-session history is cached temporarily in Upstash-backed storage. [source: pages/help.jsx][source: pages/api/support-bot.js][source: lib/agent/attachmentImageStore.js]
- Public marketing/help pages load fonts from `/fonts/` (self-hosted Space Grotesk and Manrope), so no font-related requests are made to `fonts.googleapis.com` or `fonts.gstatic.com`. The `public/landing.html` page loads Cloudflare CDN-hosted AOS animation assets, which means Cloudflare may receive standard page-request metadata such as IP address, user agent, and referrer when that page loads. [source: pages/manual.jsx][source: pages/faq.jsx][source: pages/trust.jsx][source: pages/onboarding.jsx][source: public/overview.html][source: public/landing.html][source: public/fonts/fonts.css]

## How we use your data
- Operate the service, including storing logs, equipment metadata, and alert states in tenant-scoped KV namespaces and indexing them for Dashboard views. [source: pages/api/uploadLog.js][source: pages/api/uploadEquipmentLog.js][source: lib/logs/indexMeta.js]
- Deliver account, security, operational, and customer-directed messages such as setup links, password resets, two-factor codes, alert emails, push notifications, and CSV/log exports. Depending on feature and configuration, delivery may use your configured SMTP/webhook settings or KT-managed fallback mail infrastructure. [source: pages/api/tenant/signup.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/auth.js][source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/checkNodeHealth.js][source: pages/api/sendLog.js][source: lib/tenant/mailer.js]
- Standard product messaging flows are designed for account, security, operational, and customer-directed reporting purposes; KT does not provide a general-purpose marketing email platform through the standard tenant product flows. [source: pages/api/sendLog.js][source: pages/api/auth.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/uploadEquipmentLog.js]
- Generate CSV exports for admins covering logs, equipment, alerts, tenant profile, and masked environment variables. [source: pages/api/exportTenantData.js]
- Manage billing through Stripe checkout sessions and webhooks; KT stores subscription metadata (IDs, plan, billing status) in tenant environment records but does not process card numbers itself. [source: pages/api/billing/checkout.js][source: pages/api/billing/webhook.js][source: lib/billing/stripe.js][source: lib/tenant/env.js]
- KT does not sell or share Customer Data; storage is limited to delivering the hosted service and customer-directed exports. [source: docs/reference/data-and-privacy.md]
- KT does not maintain separate backups of tenant KV data; deletes and retention changes in the configured KV are not recoverable from backups. [source: docs/reference/data-and-privacy.md]
- Passwords are stored as PBKDF2 hashes; password reset links expire after 15 minutes and are sent to the tenant contact email. Initial account setup normally uses secure setup links delivered by email and may present the setup link directly in the signup flow if email delivery is unavailable. KT cannot view plaintext passwords. [source: lib/tenant/adminAuth.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/tenant/resetPassword.js][source: pages/api/tenant/signup.js]
- If you use `/help`, KT may send the question and any supported attachments to the configured AI provider stack (`Groq`, `OpenAI`, and/or `OpenRouter`, depending on runtime configuration) to generate a response grounded in repo/doc context. [source: pages/api/support-bot.js][source: lib/agent/llm.js]

## Access and disclosure
- Admin endpoints require signed admin cookies and CSRF tokens; device endpoints require per-device HMAC signatures, and tenant scoping is enforced per request. [source: lib/auth/session.js][source: lib/auth/csrf.js][source: lib/auth/device.js]
- Non-default tenant restaurant manifests and bundle files require admin or provisioned-device context, enforced through signed device requests, admin sessions, and short-lived content-access cookies; the default demo tenant remains publicly reachable. [source: middleware.ts][source: pages/api/content/access.js][source: pages/api/listRestaurants.js][source: pages/api/restaurantContent.js]
- Environment variable reads are masked before being returned to admins, and updates are audit-logged with IP and changed fields when KV is configured. [source: pages/api/getTenantEnv.js][source: pages/api/updateTenantEnv.js][source: lib/tenant/env.js]
- Customer data is stored in tenant-scoped keys (e.g., `log:{tenant}:{type}:{device}:{timestamp}`) to avoid cross-tenant mixing. [source: pages/api/uploadLog.js][source: pages/api/uploadEquipmentLog.js]
- If you assign devices to named staff or use KT records for accountability/performance workflows, you are responsible for any employee/workplace notices, consultations, or policy disclosures your deployment requires. [source: pages/api/uploadLog.js][source: docs/legal/employee-monitoring-deployment-guide.md][source: docs/legal/terms-of-service.md]

## Retention, export, and deletion
- Default retention windows for logs, alert trackers, and live node-presence records are governed by `LOG_RETENTION_DAYS`, `ALERT_TTL_DAYS`, `NODE_LAST_SEEN_TTL_DAYS`, and `STALE_ALERT_TTL_DAYS`, with per-tenant overrides available in admin settings; retained node last-value snapshots persist until node/equipment detach or delete flows remove them. [source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/detachHubNode.js][source: pages/api/updateEquipment.js][source: pages/api/deleteEquipment.js][source: lib/tenant/env.js][source: docs/reference/retention-policy.md]
- Customers can set retention in their tenant env or delete data at any time; manual deletions and retention overrides take effect on the live KV stores targeted by the product, but not on any separate backups or history maintained outside KT by Git providers or customer-managed KV providers. [source: lib/tenant/env.js][source: pages/api/deleteTenantData.js][source: pages/api/deleteRestaurant.js][source: pages/api/buildRestaurant.js]
- Admins can export tenant data (logs, equipment, alerts, profile, masked env) via `/api/exportTenantData`. [source: pages/api/exportTenantData.js]
- Tenant data deletion requests delete operational records from the tenant-configured storage KV (or default KV if no override is configured) and delete tenant profile/env/audit records from the platform KV. Restaurant content deletions remove active bundle files and manifests but do not rewrite prior Git history. [source: pages/api/deleteTenantData.js][source: lib/tenant/storage.js][source: pages/api/deleteRestaurant.js]
- Manual logs expire automatically when the operator sets `MANUAL_LOG_RETENTION_DAYS`; if that variable is absent or zero, manual logs persist until manually deleted or until tenant/account deletion. Hub heartbeat and health summary records expire automatically when the operator sets `HUB_LAST_SEEN_TTL_DAYS`; if absent or zero, those records persist until deleted. [source: pages/api/uploadLog.js][source: pages/api/hubHeartbeat.js][source: docs/reference/retention-policy.md]
- `/help` attachment-image tokens expire after 20 minutes, support-session history expires after 24 hours by default, and cached help answers expire after roughly 1 hour unless configuration changes those defaults. [source: lib/agent/attachmentImageStore.js][source: pages/api/support-bot.js]
- See the Data Export & Deletion Policy for operational details and caveats. [source: docs/legal/data-export-deletion-policy.md]

## Cross-border data transfer
- Service operation relies on Vercel and Upstash (AWS us-east-1) and may involve processing in those regions. If you use `/help`, the configured AI provider stack may also process prompts/attachments in the regions those providers operate. By using KT, you direct data to those providers or to your own configured KV endpoint. The standard DPA, transfer addendum / SCC packet, and subprocessor schedule are published for customer review, and customer-specific signatures or redlines still run through the legal contact path. [source: docs/reference/data-and-privacy.md][source: lib/tenant/env.js][source: docs/legal/terms-of-service.md][source: pages/api/support-bot.js][source: lib/agent/llm.js][source: docs/legal/data-processing-addendum.md][source: docs/legal/transfer-addendum-scc.md][source: docs/legal/subprocessor-schedule.md]

## Subprocessors
- Hosting and routing: Vercel. [source: docs/reference/data-and-privacy.md]
- KV storage: Upstash (AWS us-east-1 by default) or customer-provided KV. [source: docs/reference/data-and-privacy.md][source: lib/tenant/env.js]
- Source/content: GitHub. [source: docs/reference/data-and-privacy.md]
- Billing: Stripe. [source: lib/billing/stripe.js]
- Messaging: customer-selected SMTP providers and webhook targets, plus KT-managed Google/Gmail-hosted mail transport for account, security, operational, and export messages when fallback delivery is used or when a feature uses KT-managed outbound email directly. [source: pages/admin/settings.js][source: lib/tenant/env.js][source: lib/tenant/mailer.js][source: pages/api/sendLog.js][source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/checkNodeHealth.js]
- Help desk AI providers: the configured runtime may use `Groq`, `OpenAI`, and/or `OpenRouter` to answer `/help` questions and inspect supported attachments. [source: pages/api/support-bot.js][source: lib/agent/llm.js]
- Support cache/media storage: Upstash-backed temporary `/help` caches and attachment-image publication flows. [source: pages/api/support-bot.js][source: lib/agent/attachmentImageStore.js]
- Browser-delivered public-page assets: Google Fonts (`fonts.googleapis.com`, `fonts.gstatic.com`) and Cloudflare CDN-hosted AOS assets on the public landing page. [source: pages/manual.jsx][source: pages/faq.jsx][source: pages/trust.jsx][source: pages/onboarding.jsx][source: public/overview.html][source: public/landing.html]
- Material additions or changes will be communicated to tenant contacts at least 30 days in advance when practical (or promptly thereafter if urgent for security/legal reasons). [source: docs/legal/terms-of-service.md]
- See `docs/legal/subprocessor-schedule.md` for the maintained customer-facing provider schedule that consolidates this list. [source: docs/legal/subprocessor-schedule.md][source: docs/legal/privacy-notice.md]