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.
- 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.
- 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.
- Every request is signed. Each call between the application and the plugin — in both directions — carries the bearer token plus 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. The plugin rejects a request whose timestamp is more than 300 seconds off its clock, and rejects any nonce it has already accepted within that window, so a captured request cannot be replayed.
- Encrypted in transit. Traffic between your browser, the store and CatalogLift runs over TLS. Stores are connected over HTTPS.
- Disconnect from either side. Disconnecting in wp-admin makes the plugin forget its credentials at once and tells us; disconnecting in CatalogLift revokes them on our side. Either way, syncing stops immediately.
The signing scheme is written down in the connector's API contract
(contracts/plugin-api/v1/security.md), and the plugin ships
as readable PHP source, so anyone can check exactly what is verified.
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, settings or files, so the application cannot ask for them even by mistake.
| What | Fields we sync | Never synced |
|---|---|---|
| Products | ID, type, status, name, slug, permalink, edit URL, description, short description, SKU, price / regular price / sale price and currency, stock status, catalog visibility, categories, brands, images (see Media), attributes with their options, SEO fields (see SEO) | Stock quantities, purchase notes, downloadable files, cost of goods, creation and modification dates |
| Variations | ID, parent product, status, SKU, prices, stock status, attribute selections, own image and effective (inherited) image | Stock quantities, SEO fields, dates |
| Categories and brands | ID, name, slug, parent and full path | Term descriptions, thumbnails |
| Global attributes | Attribute ID, name, slug, type; each value with its ID and text | — |
| Media | Attachment ID, source URL, alternative text, MIME type, gallery position, whether it is the featured image | The image files themselves, attachment titles and captions, EXIF data |
| SEO | SEO title, meta description and canonical URL as written by Yoast SEO or Rank Math, and which plugin wrote them | Redirects, sitemaps, schema settings |
| Store settings | Store URL, WordPress / WooCommerce / connector versions, currency and price formatting, site language, default product category, connector capabilities | Admin accounts, API keys, payment gateways, shipping and tax settings |
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. The plugin also keeps a small change log (which product changed, when) so we can sync incrementally instead of re-reading the whole catalog.
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. 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. 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, 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. 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 there is a monthly spending ceiling per deployment; when it is reached, AI drafts pause and the product says so.
Some checks ask a second model a narrow question about a product — whether a description matches its title, which language it is written in, whether the category fits. That model is reached through OpenRouter and receives only the catalog fields the question is about; its answer becomes a finding for you to review. These calls have a daily spending ceiling of their own.
Nothing changes on its own initiative
- Scanners are deterministic: a finding comes with the evidence that produced it, and no AI is involved in detecting a problem.
- 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.
- Eligible verified changes can be rolled back for 150 days after verification from the same screen the receipt lives on. 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: 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 — 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, and decide up to 200 drafts at once.
- Write a fix you dictate straight to a product, retry a failed apply, resume a paused apply queue, roll a change back, and pause or resume monitoring.
- Publish a new 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; 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 decision it makes is stamped with the door it came through and shown to you that way.
Risky writes 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. 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 click 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 while a store is connected. When you delete a store it stays restorable for 14 days and is then purged — immediately if nobody ever approved anything for it. Disconnecting the plugin stops syncing at once. Deleting your account removes your data on 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 and a CSRF token. 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 one third-party script in the product is Paddle's checkout, loaded on the billing screen when you open a checkout.
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.