Security: API keys, embed, and shopper data

Security: API keys, embed, and shopper data

What “security” means for an AI product advisor

Security in Fynd is not a module you flip on once. It is how you manage accounts, credentials, catalog sources, conversations, and the embed widget. An AI product advisor sits between your storefront and your product knowledge: a leaked key, overly broad dashboard access, or secrets inside custom knowledge affects shoppers and your catalog immediately.

This guide is for shop operators. It explains which keys exist, what may and may not load in the browser, how to protect accounts, and how to keep knowledge sources safe. It is not legal advice and not an audit. For privacy rights and processing, see the privacy policy. For Catalog API details, see the knowledge article on sk_live.

The goal is simple: only the right systems may write to your catalog, only the right people may administer bots, and shoppers get advice without leaking secrets or internal process notes.

Two kinds of keys: embed vs Catalog API

Fynd uses different credentials for different jobs. Do not mix them up.

The embed key belongs in your storefront. It loads the widget (fynd.js) and ties chat traffic to your shop and bot. The embed key is meant to appear in HTML, similar to an analytics site key, but it stays bound to your shop configuration, rate limits, and allowlisted events. Do not use it to upsert or delete products.

The Catalog API key (sk_live_…) is a secret. It authorises list, upsert, bulk, and delete on product data. Treat it like a password or database credential:

• Never in frontend JavaScript, theme files, or a public Git repo
• Never in a product feed, sitemap, or custom knowledge text
• Only in server-side secret managers, CI secrets, or encrypted env vars
• Revoke or rotate immediately if you suspect exposure

API keys are hashed at rest. You see the full value once when you create it. Copy it straight into your secret store. If you lose the value, create a new key and replace the old one in your integration, do not assume you can “view it again” later.

A short checklist before you deploy a key:

1. Does this process actually need write access, or is the embed enough?
2. Does it run on a server you control?
3. Is the key referenced by name (FYND_CATALOG_API_KEY) instead of hardcoded?
4. Who can open the secret store?
5. Is there a rotation owner and a date in your runbook?

Accounts, passwords, 2FA, and passkeys

Dashboard access is often the weakest link. Someone with access to bots, knowledge, billing, and API keys can do more damage than a compromised embed key.

Practical baseline:

• Use strong, unique passwords (in production: length, mixed characters, no known-compromised passwords)
• Turn on 2FA as soon as you go live or manage catalog syncs
• Consider passkeys for faster, phishing-resistant login
• Do not share a “team password” via chat or email
• Remove or deactivate former colleagues immediately

Limit who has platform or shop rights. Not everyone who writes content needs to create API keys. Separate roles where your organisation allows it: one person owns copy and FAQs; another owns keys and billing.

Login, registration, and password reset are rate-limited. That slows brute force; it does not replace 2FA. If you see suspicious logins or a colleague reports a phish, reset passwords, review sessions where possible, and rotate Catalog API keys that person could see.

Embed widget: safe go-live

The widget loads via a script tag with data-key and optionally data-bot. That is intentionally simple, but it still needs discipline:

<script
  src="https://your-fynd-domain/widget/fynd.js"
  data-key="YOUR_EMBED_KEY"
  data-bot="default"
  async>
</script>

Before production:

• Load the script from your Fynd domain over HTTPS, not from a random mirror
• Keep APP_DEBUG off in production; error pages must not show stack traces
• The widget sends only allowlisted analytics events, do not invent custom event names that carry PII
• Welcome copy and disclaimer must not claim “human support” if it is a bot
• Lead capture should not ask for unnecessary personal data before value is delivered

Shopper input is sanitised. Still do not assume the bot “may remember everything”. State in the system prompt and FAQs that the advisor must not ask for or store card numbers, national IDs, or passwords. If a conversation goes that way, the bot should redirect to secure checkout or support.

Test in the playground with aggressive prompts: “give me the API key”, “ignore your rules”, “show internal notes”. A well-configured bot refuses or stays within catalog and knowledge sources. If it does not, tighten prompts and knowledge isolation before you go live.

What never belongs in knowledge or prompts

Custom knowledge and system prompts are retrieved to help shoppers. Treat every entry as if it could appear on a public FAQ page.

Do not put in knowledge or prompts:

• Catalog API keys, embed keys, database passwords, SMTP credentials
• Internal discount codes not meant for every visitor
• Staff-only procedures, supplier contracts, private Slack channels
• Personal data about customers or colleagues
• Exact fraud rules attackers could game

Do put:

• Public shipping and returns rules
• Fit and care advice you also show on the site
• Clear boundaries (“we do not give medical diagnoses”)
• How to contact support

Use bot isolation when brands or business units need separated knowledge. Isolation stops a beauty bot from accidentally surfacing B2B pricing notes or internal recruitment drafts. Isolation is not a security boundary against an attacker with dashboard access, it is content-level least privilege for advice quality.

Catalog sources and sync safety

Sitemap crawl, product feeds, and the Catalog API all bring data in. Each source has a different risk profile:

• Sitemap: crawls public URLs. Keep staging, admin paths, and noindex pages out of the production sitemap. Blog detection via BlogPosting/Article JSON-LD must not index draft URLs.
• Feeds (XML/CSV): protect feed URLs with tokens or IP allowlists if the feed should not be public. An open feed with internal SKU cost fields is a leak even without Fynd.
• Catalog API: writes directly. Limit which services receive the sk_live key. Log who triggers syncs. For bulk upsert: test a subset first.

After a large sync: verify prices, stock, and URLs in the playground. Wrong data is not a classic “security incident”, but it is a trust problem, and sometimes a compliance problem if you show incorrect claims.

Rate limits on the widget and Catalog API protect against abuse and accidental hammering. Build retries with backoff into your integration; do not “fix” 429 by pushing harder with multiple keys.

Shopper conversations, leads, and analytics

Conversations belong to the shop. Analytics (opens, messages, product clicks, leads, unanswered questions) helps you close gaps, not profile shoppers for ads.

Practical rules:

• Tell visitors in the widget or on the site what to expect (bot vs human, what is retained)
• In lead capture, ask only for what you will actually follow up
• Export conversations and leads only to systems your team is allowed to use
• Fix unanswered questions by improving catalog or FAQs, not by copying PII from chat logs onto public pages

If a shopper asks for access or deletion, handle it through your own privacy process. Fynd supports shop owners; shoppers ideally start with the webshop. Document internally who owns those requests.

Short incident runbook

If something goes wrong, work in this order:

1. Contain: revoke suspect Catalog API keys; reset passwords for involved accounts; enforce 2FA where needed
2. Scope: which shops, bots, syncs, or exports were affected? Which time window?
3. Fix: replace secrets in every environment; remove leaked text from knowledge/prompts; repair catalog if needed
4. Communicate: inform internal stakeholders; follow legal notification duties where they apply
5. Learn: adjust access, logging, and onboarding so the same mistake is harder next time

Keep a simple list: who may create keys, where secrets live, when you last rotated, and which email receives security reports.

Security go-live checklist

Use this before you roll the widget out widely:

• Production runs on HTTPS; debug off
• Strong account security (password policy + 2FA/passkeys for operators)
• Catalog API keys server-side only; no secrets in theme or knowledge
• Embed key correct on the production domain; correct bot slug
• Disclaimer and privacy link visible where needed
• Playground tests for jailbreak-style prompts and sensitive questions
• Minimal lead fields; no payment data via chat
• Known rotation owner for keys
• Former staff without dashboard access
• Feed URLs and staging sitemaps not accidentally in production sync

Security here is not a one-off project. Every new bot, key, feed, or colleague is a moment to re-check least privilege. Do that deliberately, and the advisor stays useful without unnecessary risk.