How to deliver an n8n chatbot without exposing the workflow webhook.

A browser widget is public code. A production Chat Trigger URL should not become public configuration. The delivery layer between them should validate the website, bound the request, protect the destination, and give the client evidence that the service works.

1. Prepare the production n8n Chat Trigger workflow

Start with an active production workflow that accepts chat input and returns a supported response field such as output, text, or message. Test the workflow directly before adding a delivery layer. This separates workflow problems from website or relay problems.

Use the production webhook, not a temporary editor test URL. Keep that URL server-side.

2. Put a protected relay in front of the webhook

The website should call a public bot identifier on your relay. The relay should resolve that identifier to the protected destination only after validating the request. It should reject private, loopback, link-local, metadata, and unsafe redirect destinations so the configured webhook cannot become a server-side request forgery path.

3. Allow exact website origins

Declare each approved origin with its full scheme and host, for example https://www.example.com. Do not use wildcard origins for client chat. Treat the origin check as one boundary, not as visitor authentication. Chat visitors do not need accounts.

4. Bound and test the public request

Set request-size limits, message-length limits, concurrency limits, timeouts, and rate limits before forwarding anything. Do not follow redirects to an unvalidated destination. Run a synthetic message through the same public path the website will use, then verify the response and timing.

5. Brand and embed the widget

Configure the title, greeting, placeholder, launcher, starter prompts, colors, position, and theme. Preview on desktop and mobile. Then add the generated script to the approved client website and repeat the synthetic test from that exact origin.

6. Give the client evidence, not admin access

Report conversation starts, successful messages, failures, and response time without exposing webhook configuration or owner controls. Use a revocable report link. Store message bodies only when the customer has deliberately enabled an appropriate retention window.

Where BotLatch fits

BotLatch packages this delivery boundary into one self-hosted agency installation: protected relay, exact origins, branded widget builder, synthetic test, aggregate usage, and revocable client reports. The customer's installed BotLatch host and configured downstream services carry chat traffic. BotLatch.com does not.

Purchasing does not create a centralized account. After installation, the buyer visits /setup on that installation to create its single local owner account. Additional registration then closes.

BotLatch is an independent product. It is not affiliated with or endorsed by n8n.