WebShopFactory

Status: Planned feature / architecture proposal. This page describes intended behavior and boundaries. It does not claim that WebShopFactory is available yet.

WebShopFactory is a planned ToolsAPI service for creating, reviewing and publishing product copy for connected webshops.

The core idea is:

1. Connect a webshop.
2. Import factual product data.
3. Add traceable keyword/search evidence.
4. Generate product-copy drafts with AI.
5. Review and edit the draft.
6. Explicitly approve and publish it back to the shop.

The service is intended to stay platform-neutral instead of becoming a WooCommerce-only feature.

First target platforms

The first planned shop adapters are:

• WooCommerce
• PrestaShop
• Magento 2 / Adobe Commerce

Each platform adapter is responsible for translating between the remote shop API and one normalized WebShopFactory product model.

Provider support must be reported honestly. A planned or scaffolded adapter is not presented as working import/publishing support until its contract has actually been implemented and verified.

Planned ToolsAPI surfaces

WebShopFactory is intended to use the normal Tools application structure:

• /me/webshop-factory - owner workspace for shop connections, products, keyword evidence, drafts, review and publication history.
• /admin/webshop-factory - global provider status, diagnostics, configuration and audit views.
• /api/webshop-factory - unversioned owner/client API.
• /public/webshop-factory/ - standalone React frontend-helper/demo that talks only to the API.

The service should be discoverable through the normal Tools service surfaces, but it is not planned for the main navbar.

A later standalone frontend repository can be split out without moving the API away from ToolsAPI.

Keyword and search evidence

Keyword data is a separate source layer from AI generation.

Search volume, ranking, CPC, competition or similar metrics must never be invented by the language model. Every metric must retain its source/provider, market, language and observation time.

Potential evidence providers include:

• manual CSV/JSON import;
• Google Search Console for site-specific query performance;
• DataForSEO or another dedicated keyword-data provider;
• future provider adapters.

Google Search Console performance data and general market search-volume data are different concepts and must stay labelled as such.

The first implementation may start with manual/imported evidence before a live statistics provider is configured.

AI generation

Generation should reuse the existing Tools internal OpenAI infrastructure with a dedicated WebShopFactory client profile.

The prompt contract keeps these inputs separate:

• factual product data from the shop;
• current product copy;
• keyword/search evidence and provenance;
• owner instructions;
• target market/language;
• requested output fields.

The model must not invent product facts or keyword metrics.

Candidate generated fields include:

• product title suggestion;
• short description;
• long description;
• SEO title;
• meta description;
• suggested slug;
• primary/secondary keyword suggestions.

Review and publication

Generation and publication are separate operations.

The initial implementation requires explicit approval before anything is written back to a webshop. There is no planned "generate and immediately publish" mode in the first slice.

A publication action must verify ownership of the shop connection, product and approved draft before calling the remote provider.

Failures must not mark content as published or destroy the last usable draft.

Security and observability

Planned requirements include:

• owner-scoped authorization on connections, products, evidence, drafts and publications;
• owner-bound webshop.manage API scope for external/API clients;
• encrypted shop credentials at rest;
• explicit administrator authorization for global management;
• CSRF protection for browser-session mutations;
• rate limits around connection tests, synchronization, AI generation and publication;
• public-network/SSRF protection for configurable remote shop URLs;
• structured audit records for meaningful operations;
• always-on safe operational failure reporting through the normal #toolsapi diagnostics path.

Credentials, authorization headers, full product bodies and generated copy must not be copied into operational diagnostics.

Standalone React helper

The planned /public/webshop-factory/ application is a frontend helper/demo, not a second backend.

It should:

• contain no Laravel runtime dependency;
• use only the documented WebShopFactory API;
• avoid embedding shop/provider secrets in JavaScript;
• use the same owner workflow as the normal Tools GUI;
• be easy to move into a dedicated repository later.

The normalized product model, provider adapters, AI generation rules and publication logic remain in ToolsAPI.

Expansion

The same architecture should be able to add:

• more webshop platforms;
• multiple shops per Tools user;
• multiple languages/store views;
• category and landing-page copy;
• translation/localization;
• media alt text;
• batch review;
• scheduled product refresh;
• stale-copy detection;
• brand/style profiles;
• A/B variants;
• richer SEO integrations.

The implementation is tracked internally in issue #2321.