InformlyInformly Docs
Chat Widgets

Security

Lock down an Informly widget with allowed origins, PII masking, rate limits, and the right handling of public and server-side keys.

A widget runs in the customer's browser, which means anything you put in the embed snippet is technically visible to anyone who views your page source. That's fine — the public key is designed to be public — but a few security settings keep you in control of where the widget loads, what data leaves the browser, and how much traffic any one user can generate.

You'll find these settings on the widget detail page under Security. Configure them before you embed the widget on a production site.

Where to find it

Go to Widgets → (your widget) → Security.

API keys

Each widget has two keys:

KeyWhere it's usedSafe to expose?
public_keyEmbed snippet, browser codeYes — it's the widget's public identifier
Server-side secretBackend-only calls to the Informly APINo — server-side only

Never paste the server-side secret into client code, a public repository, or anywhere a browser can read it. If a secret is exposed, rotate it from the Security tab and update any backend that uses it.

Allowed origins (CORS)

Allowed origins is a list of domains where the widget is allowed to load. The Informly script checks the page's origin against this list before initializing; anything not on the list gets rejected.

Add your production domain

Enter the exact origin — for example https://acme.com — and click Add. Repeat for any subdomains the widget needs (https://app.acme.com, https://www.acme.com).

Add a staging domain if needed

Add https://staging.acme.com or your preview-deploy URL so you can test before going live.

Save

Click Save origins. The check applies on the next page load that includes the widget script.

Leaving the origins list empty allows the widget to load on any domain. That's convenient for development but should never be the production setting — someone could embed your widget on a phishing site and consume your conversation quota.

PII detection

PII detection masks emails, phone numbers, and credit card numbers in the customer's messages before they reach the language model. The customer sees their message echoed normally; the LLM sees a masked version.

Turn this on if:

  • You operate in a regulated industry (healthcare, finance, government)
  • Your privacy policy promises that PII isn't sent to third-party processors
  • You want a layer of insurance against customers pasting sensitive data by accident

The masking is reversible inside Informly (so a human agent can still see the original on the inbox) but the LLM never sees the raw values.

Rate limiting

Rate limits cap how much one IP address or one conversation can spend in a window of time. They protect you from abuse — scripted attacks, runaway bots, or a single user who finds an expensive loop.

LimitDefault behavior
Per-IP messagesCap messages from one IP in a rolling window
Per-conversation messagesCap messages within one conversation thread

Pick values that comfortably exceed normal usage. If a typical conversation is 5–10 messages, a per-conversation cap of 50 is generous; lower it if you see abuse. Hitting a limit returns a friendly error to the customer and logs the event in Analytics.

For a public-facing production widget, the minimum security setup is:

  • Allowed origins limited to your production and staging domains
  • PII detection on if you handle anything more sensitive than marketing chat
  • Rate limits set to roughly 5x normal usage
  • Server-side secret kept out of all client code and version control

What's next

On this page