An assistant that knows your e-shop as well as you do.

Key principles

• Server-side LLM calls. Neither the Anthropic key nor your API key ever reaches the browser. They always stay on our server, encrypted.
• Streaming over Server-Sent Events. The reply types out character by character like ChatGPT. No 10-second wait for the whole text.
• In-process IIS hosting. ASP.NET Core, ANCM V2, Windows Server. A traditional stack, no Docker overhead, no Kubernetes complexity.
• Stateless orchestrator, stateful DB. Conversation state lives in MSSQL, not in RAM. Horizontal scaling without session affinity.
• Multi-tenant per widget. Each client has its own widget_id with its own configuration, system prompt and enabled tools.

MCP-native architecture. We support the Model Context Protocol standard — if you have an MCP server, connecting takes an hour. If you have a standard REST API, the MCP facade is a few hours of work on our side.

What we support

Embed snippet (everything you put on your e-shop)

<!-- Paste before </body> -->
<script async
        src="https://chat.e-shop.report/widget/loader.js"
        data-widget-id="your-widget-id"></script>

Configuration via the admin API (optional)

If you want to manage widgets programmatically (e.g. multi-tenant deployment through your own portal), we provide a REST API with X-Admin-Key authentication:

curl -X POST https://chat.e-shop.report/api/admin/widgets \
  -H "X-Admin-Key: <your-secret>" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"clientName":"Demo e-shop","mcpBaseUrl":"https://api.demo-eshop.com",...}'

Test connection

There's a button in the admin that sends a test request to your API and tells you immediately whether it works. You don't have to wait for the first conversation to find out something's wrong.

Key encryption. We store client API keys in MSSQL as VARBINARY encrypted with AES-256 (AES-GCM, master key in the .NET app). The master key never leaves the server. Plaintext keys aren't returned even via the admin API — endpoints return only hasApiKey: true/false.

PII masking in the log. Customer emails in chat_messages are stored masked ([EMAIL]). Plaintext goes only into the LLM context, never into the persistent history. In line with the GDPR data-minimization principle.

Unified error for order lookup. For both "order not found" and "email doesn't match" we return the same HTTP response. An attacker can't enumerate the email database by guessing.

CORS / frame-ancestors per domain. The widget refuses to load from a foreign domain. Access-Control-Allow-Origin is always the client's specific URL from the DB, never *. CSP frame-ancestors as a second layer of protection against embedding with a stolen widget-id.

Rate limiting. Per IP + per session + per widget. By default 30 messages/hour per IP. A hard cap on tokens per session. Black Friday-proof.

Audit log. Every tool call, latency, success rate, tokens used — in the chat_tool_calls table with 12-month retention. Available via the admin API and directly over SQL for advanced analysis.

GDPR compliance

• DPA (Data Processing Agreement) to sign as part of the contract
• Right to erasure — cascade via session_id, complete deletion of a conversation within 7 days of the request
• Data minimization — we don't store anything we don't need

Hosting. A Tier 3 data center in the EU. No data transfer outside the EU. Anthropic API region: EU (Frankfurt).

Penetration testing. A regular annual pen test by an external firm (report available under NDA for Enterprise clients).