How CatalogLift connects to your store, and what it can and cannot touch.

How the connection works

You install one WordPress plugin — the CatalogLift connector — and press Connect in wp-admin. No Jetpack, no WordPress.com account, no WooCommerce REST API keys to paste, no admin password ever leaves your site.

1. Handshake. The plugin creates a one-time handshake with its own short-lived secret and sends you to CatalogLift to say which workspace the store belongs to. CatalogLift reaches the store at its own address to confirm the handshake really came from it; the store answers exactly once and never again, and a handshake expires after fifteen minutes.
2. Credentials. Once you confirm, the store receives its own API token and signing secret. They belong to that one store; other stores in your workspace get their own. On our side both are stored encrypted at rest.
3. Every request is signed. Once the store is connected, each call between the application and the plugin — in both directions — carries an HMAC-SHA256 signature over the method, path and query, a UTC timestamp, a random nonce and a hash of the body, computed with the signing secret; calls from the application to the plugin also carry the bearer token. Each side rejects a request whose timestamp is more than 300 seconds off its clock, and any nonce it has already accepted within that window, so a captured request cannot be replayed.
4. Encrypted in transit. Traffic between your browser, the store and CatalogLift runs over TLS. Stores are connected over HTTPS.
5. Disconnect from either side. Disconnecting in wp-admin makes the plugin forget its credentials at once and tries to tell us; disconnecting in CatalogLift revokes them on our side and asks the plugin to forget them too. Either way, syncing stops. While a batch of changes is being written to the store, a disconnect waits until the batch finishes.

The plugin ships as readable PHP source in the WordPress plugin directory, so anyone can check exactly what it signs and verifies.

What leaves your store

The connector exports the product catalog and nothing else. The endpoints it exposes are fixed by contract; there is no endpoint for orders, customers, coupons, reviews, users or files, so the application cannot ask for them even by mistake. The only store settings it reports are the ones in the last row below.

Never, under any plan: orders, customers and their e-mail addresses, payment details, admin or customer accounts, coupons, reviews, analytics, or the image files themselves. (For an alt-text draft, CatalogLift fetches that one image from its public address in your store — see what the AI provider receives.) The plugin also keeps a small change log (which product changed, when) so we can sync incrementally, with a periodic full pass to catch anything missed.

Where your data lives

The application, its database, queues and daily VPS backups run with OVHcloud in Frankfurt, Germany (European Union). VPS backups are on separate servers in the same datacentre. Every hour we also take an off-site backup of the database, the application's configuration and its stored files; it is encrypted on our server before it leaves and kept in a private Backblaze B2 bucket in the EU (Amsterdam) for a limited period — at least seven days, because each copy is locked against deletion for that long. Your catalog copy, findings, drafts and change history are stored per workspace and per store, and every query in the product is scoped to the workspace that owns the data — an agency's clients never see each other. Access to production systems is limited to the people who operate the service, behind individual accounts with two-factor authentication.

We use OVHcloud Zimbra in France for correspondence and Resend for transactional e-mail. Resend sends through Ireland but stores message content and delivery logs in the United States. Delivery to a recipient's mail server uses opportunistic TLS: encryption is attempted, but a receiving server that does not support TLS may receive the message without it. Ploi manages server deployments and configuration, Backblaze stores the encrypted off-site backups, and Cloudflare Turnstile screens the public contact form for bots. The Privacy policy lists the providers, their roles and international transfers.

What the AI provider receives

Drafts are produced by a large language model from OpenAI over its API. For one draft we send the fields of the product in question — title, descriptions, SEO title and meta description, attributes and variation attributes, category and brand names, image alt text — the evidence the scanner found, your store's name and playbook, and the language to write in. When a finding is about several products, such as a duplicated description or an image they share, the titles and text of up to five of them go along. For an alt-text draft we also send the image itself: CatalogLift fetches it from its public address in your store and sends a scaled-down copy, because alt text has to describe what the picture shows. Together with the request go strict instructions that catalog text is data, not commands, and that the model must decline rather than guess.

We never send store credentials, orders, customers, e-mail addresses, payment data or anything about a person. Under the provider's API data-usage terms, data sent through the API is not used to train its models. Every call is metered, and behind your plan's allowance of AI runs each workspace has a spending ceiling per allowance period; if it is ever reached, drafting waits for the next period.

Five checks ask a second model a narrow question about a product — whether a description matches its title, which language it is written in, whether it tells a shopper anything concrete, whether its attributes contradict it, and whether the category fits. That model is reached through OpenRouter and receives only the catalog fields the question is about, plus, for the category question, the store's list of categories. It answers with a probability, never text; its answer can open a finding for you to review or close one it no longer supports. These calls have a daily spending ceiling of their own.

Nothing changes on its own initiative

• Most checks are plain rules; the few checks of meaning described above ask a decision model for a probability, never for text. Either way a finding comes with the evidence that produced it.
• The model only ever drafts. A draft is a structured, validated proposal with evidence, a confidence level and a before/after diff, and it sits still until somebody with authority decides on it.
• That decision is made under your workspace's authority — by a person in the panel, or by an AI agent you connected and granted that authority. Only decided changes are written to the store, in small batches, through the same signed channel.
• Every write is read back from the store and re-scanned, so the product shows what actually landed, not what it intended.
• Retries never double-write: each operation carries an identity the plugin remembers, so a lost response is replayed, not repeated.
• Every applied change carries a receipt naming who decided it and through which door — the panel, or an agent working on their behalf.
• On a paid plan, eligible verified changes can be rolled back for 150 days after verification from the same screen the receipt lives on, while the store is connected. Availability depends on the previous value and connector support.

What a connected agent can do

You can connect an AI assistant of your own — Claude, ChatGPT, Claude Code or your own code — to CatalogLift over its MCP server. Connecting one is a one-time OAuth consent, and that consent is a grant of authority: from then on the agent works the loop with the same reach you have in the panel, on your account, until you cut it off. Being plain about the size of that grant matters more to us than making it sound smaller than it is.

The agent can:

• Read everything you can read in the loop: the day's digest, findings with their evidence, the review queue, receipts, the playbook, your AI allowance.
• Run a catalog check and a scan, exactly as the buttons do.
• Order AI drafts against your playbook — for SEO titles, meta descriptions, short descriptions and alt text, up to 50 in one batch — spending your workspace's monthly allowance as the panel does.
• Approve a draft and send it to the store in one step, reject one, and decide up to 200 drafts of one kind on one store at once.
• Write a fix you dictate to a product with an open finding, retry a failed apply, resume a paused apply queue, roll a change back, and pause or resume monitoring.
• Dismiss or restore a finding, and turn checks on or off for a store.
• Save, discard and publish a version of your playbook, which changes the rules every future AI draft is written against.

The agent cannot:

• Go beyond your plan. A Free workspace connects no agent at all; drafting for or writing to a store past your plan's limit is refused in words, not silently skipped.
• Reach a store outside your workspace. A store id that is not yours is an error, never a wider answer.
• Skip the gates the button goes through: the same locks, the same refusal to ship stale work, the same read-back and re-scan afterwards.
• Spend outside your allowance, or hide. Its AI drafts come out of the same monthly pool, its requests are rate-limited, and every draft it orders and every approval, rejection, fix and rollback it makes is stamped with the door it came through and shown to you that way.

Batch approvals and changes to checks or the playbook are priced before they happen: the agent first receives the impact — how many products a decision touches, how many assessments a new playbook re-opens — and then confirms exactly what it was quoted. A single approval, a dictated fix or a rollback goes straight through, as it would from you in the panel. That protects a yes from drifting onto a different set of products; it is a consistency check on the agent's own step, not a second pair of hands.

Cutting an agent off takes one button and a confirmation on the Agents screen, on any plan, including after a downgrade to Free. The tokens it holds are revoked there and then, and a token that was already being issued when you clicked dies on arrival rather than slipping through behind the decision. What a connected agent is for, and what you see after it has worked, is on the agents page. Disconnecting stops what comes next; it does not undo what the agent has already done — that is what rollback is for.

Access and retention

Catalog data is kept until you delete the store: disconnecting the plugin stops syncing but keeps the copy. When you delete a store it stays restorable for 14 days and is then purged — immediately if no decision was ever recorded for it. Deleting your account removes your login, and the stores of a workspace nobody else belongs to follow the same schedule; the exact periods, including for logs and billing records, are in the Privacy policy. You can ask for a copy or for deletion at any time at hello@cataloglift.com.

Your account

Passwords are hashed with a modern algorithm and never stored in clear text. Two-factor authentication (TOTP) and passkeys are available to every account, and sign-ins are rate-limited. E-mail addresses are verified before a workspace can connect a store.

No tracking cookies

Neither these pages nor the application carry advertising scripts or tracking cookies — only a session cookie, a CSRF token and, if you tick “Remember me”, a sign-in cookie. The public pages count visits with Fathom Analytics, which sets no cookie, builds no profile and leaves out browsers that send “Do Not Track”; the privacy policy says what it receives. The application carries no analytics script at all. The third-party scripts are Paddle's checkout, loaded on the billing screen and on payment links when you open a checkout, and Cloudflare Turnstile on the contact form.

Responsible disclosure

If you believe you have found a vulnerability in CatalogLift or the connector plugin, write to security@cataloglift.com with enough detail to reproduce it. We acknowledge reports within two business days, keep you informed while we fix the issue, and will not take action against good-faith research that respects other customers' data and does not disrupt the service. Please do not test against stores or workspaces you do not own.

Questions this page does not answer: write to us. See also the Privacy policy, the Terms of Service and the Refund policy.