Privacy Policy

Privacy Policy

Last updated: July 14, 2026

This policy describes the information Parsely handles when you use the web app, public recipe parser, personal cookbook, sharing features, Ask Chef, and MCP integrations.

Information Parsely Handles

Account information

• Clerk account identifiers and the profile details you provide through Clerk, such as your name, email address, and profile image.
• Parsely's internal user identifier and the records needed to connect your Clerk account to your Parsely data.
• Authentication cookies, tokens, and session information needed to sign you in and protect your account.

Recipes and cookbook information

• Public-web recipe URLs you submit and the content extracted from those pages, including titles, images, ingredients, instructions, timing, and other recipe metadata.
• Your saved-recipe links, folders, tags, pins, favorites, serving choices, ingredient checks, recipe overrides, and display preferences.
• Private recipe records uploaded by supported native clients and linked to your account.
• Random share tokens while you choose to keep a user-specific recipe share link active.

AI and operational information

• Recipe content, URLs, Ask Chef questions, and relevant recipe context sent for AI processing when those features are used.
• Operational records such as parse outcome, model, token counts, feature used, rate-limit state, and timestamps.
• Manually selected product events with coarse properties such as feature surface, outcome, and count buckets. Analytics properties are designed to exclude names, email addresses, recipe content, prompts, raw URLs, and share tokens.

Network and rate-limit information

Network requests expose an IP address to the network and hosting services that deliver them. Parsely uses a trusted proxy address only long enough to create a keyed HMAC rate-limit bucket. The application sends that bucket, not the raw address, to Convex. Guests also receive a random, signed session cookie so Parsely can apply fair-use limits.

MCP connections and API keys

• Whether you enabled signed-in MCP cookbook access and when that choice changed.
• For personal MCP API keys: the name, public selector, access scopes, keyed digest, creation and last-used times, expiration, and revocation status.
• A one-way digest of the Clerk reverification identifier used to ensure one verification cannot create more than one key.
• The raw API-key secret is shown once when created and is not stored by Parsely.

How Parsely Uses Information

• Provide authentication, recipe parsing, cookbook organization, sharing, and Ask Chef.
• Authenticate MCP clients, enforce the access you selected, and perform requested cookbook reads or writes.
• Apply rate limits, prevent abuse, and protect the service.
• Operate, troubleshoot, and measure the reliability of parsing and AI features.
• Understand which product features are useful through limited cookieless browser analytics and pseudonymous server events.
• Respond to support or privacy questions you send to us.

Connected MCP Clients

When you connect an MCP client, Parsely sends the cookbook fields needed for the tools you ask that client to use. This can include recipe titles, folders, ingredients, instructions, images, source URLs, favorites, pins, and other saved-recipe state. A write-enabled key can also let that client create folders, change a saved recipe's folder, favorite, or pin state, and remove a recipe from your cookbook.

The client, model provider, workspace administrator, or other service you choose may process or retain transferred information under its own terms and privacy policy. Review that service before connecting it and keep approval prompts enabled for writes.

Google may be the sign-in method behind your Parsely account, but Parsely never sends a Google access token to an MCP client. OAuth clients receive a resource-bound Clerk token; clients using a personal API key receive only the key you copied into that client.

Public Catalog and Share Links

Public-web recipe submissions are not private. When you submit a publicly accessible recipe URL, Parsely may add the URL and parsed recipe content to a shared catalog. Catalog recipes have public recipe pages, may be included in sitemaps, and may be indexed by search engines. They can remain available even if you later remove the recipe from your cookbook or delete your account because the catalog row is shared and is not linked to the submitting account.

Your cookbook organization, private recipe overrides, and private native-client recipes are separate account-linked records. A share link makes the associated user-specific recipe view available to anyone who has its random token. Revoking the link, removing the saved recipe, or deleting the account removes that active token access.

Service Providers

Parsely relies on these services to operate:

• Clerk provides web authentication and account management.
• Convex provides application data storage and server functions.
• Netlify hosts and delivers the web application and API routes.
• Google Gemini processes recipe content when deterministic extraction is insufficient and processes Ask Chef questions with the relevant recipe context.
• Jina AI's reader service may fetch a submitted public URL when the recipe site blocks Parsely's direct fetch.
• PostHog receives manually selected cookieless browser events and pseudonymous server events. Its browser client is configured for memory-only use with no persistent person profiles, automatic capture, session replay, automatic exception capture, performance capture, surveys, experiments, or feature flags.
• Self-hosted Umami measures aggregate page traffic in cookie-free mode after page titles and query-string or fragment data are removed from page and referrer URLs.

Cookies and Browser Storage

Clerk uses the browser mechanisms needed to maintain authenticated sessions. Parsely sets a signed, HttpOnly, SameSite guest-session cookie for up to 14 days to enforce guest limits. PostHog is configured not to use cookies or persistent browser storage, and Umami runs without analytics cookies.

Parsely stores some product data in your browser: Ask Chef conversation history (including questions, responses, and recipe-change proposals), unfinished Ask Chef drafts, recently opened recipe identifiers and titles, guest serving and ingredient checklist choices, cook-mode progress, and local display preferences. Conversation history, recipe choices, progress, and preferences use local storage; unfinished drafts and sign-in redirects use session storage. This keeps those features available across navigation or reloads on that browser.

Retention and Account Deletion

Parsely keeps account-linked application records while they are needed to provide the service and keeps operational records as needed for reliability, security, and abuse prevention. Revoked or expired MCP API-key records are normally removed by a daily cleanup after a 30-day retirement window. Service providers may maintain their own operational logs or backups under their policies.

The account deletion control in Settings starts removal of the Clerk account and purges saved cookbook records, folders, preferences, private recipes, MCP API keys and grant state, active share-token records, and user-linked Convex parse and AI usage logs. If Clerk deletion is temporarily unavailable, Parsely records and retries that deletion.

After backend deletion succeeds, the web app asks the current browser to remove Parsely-owned chat histories and drafts, recent recipes, serving and checklist choices, cook progress, sign-in redirects, and local preferences. It removes only known Parsely keys rather than clearing unrelated origin storage. If browser storage is blocked or unavailable, local copies may remain until you clear Parsely's site data through your browser settings.

Deletion tombstones may retain limited account identifiers, including a normalized email address, legacy customer ID, and Clerk subject. A disabled user record and pending or exhausted Clerk deletion retry records may also retain authentication identifiers. Parsely uses these records to complete retries and prevent deleted accounts or entitlements from being silently recreated. Keyed audit records and limited security and rate-limit records may also remain. Account deletion cannot retract pseudonymous analytics events already sent to a provider. Shared public catalog recipes are not account-linked and may remain publicly accessible and indexed after deletion.

Your Choices and Questions

You can update supported profile and cookbook settings, disable signed-in MCP access, revoke individual MCP API keys, and delete your account from Settings. Disconnect or clear the connection in your chosen MCP client separately. For access, correction, deletion, or other privacy questions, contact us at:

Policy Changes

If this policy changes, Parsely will post the revised version here and replace the fixed "Last updated" date above.