How to Secure SeaText AI JavaScript Integration

Secure a SeaText AI JavaScript integration by keeping your API key out of the browser. The JavaScript snippet itself is public, so treat anything inside it as readable by visitors. Put the key in a server-side proxy or environment variable, let your own backend call SeaText using that secret, and have the page talk to your backend instead.

SeaText's installation process is secure and the AI remains inert until activated. That protects your content, but it does not protect a hard-coded key. A visitor can open DevTools, read the page source, and see any key that lives in client-side code. This article walks through the mistakes that cause leaks and the exact setup that avoids them.

The security goal: keep secrets out of the HTML

Your browser code is not private. Every JavaScript file, script tag, and data attribute is downloaded by anyone who visits. That means there is no secret storage in the frontend.

So the main decision is not which key is safest. It is where does the key live. The answer: on a server or in an environment variable your server can read. The page never needs to see the key if you create one small endpoint that adds the key for you.

This is a common pattern. Your website asks your server for SeaText content. Your server adds the API key and calls SeaText. Your server returns the content to the page. The browser only ever talks to your domain.

Ordered steps to secure the integration

Prerequisites

• SeaText AI account.
• A valid, real production domain. Localhost is restricted.
• Access to a server, serverless function, or hosting platform where you can set environment variables.
• The JavaScript code from your SeaText account's General Integration page.

Setup steps

1. Create your SeaText account and copy the provided JavaScript code. Place it on the exact domain associated with your account.
2. Store your API key as an environment variable on your server. Name it something like SEATEXT_API_KEY and never put it in HTML, CSS, or public JavaScript.
3. Create a server-side proxy endpoint. For example, /api/seatext accepts the same request your page wants to make, reads the environment variable, calls SeaText with the key, and sends the response back to the browser.
4. Point your page's JavaScript at your proxy instead of at SeaText directly. The page sends normal requests to your origin; the proxy handles the secret.
5. Use one account per domain. Each SeaText account is linked to a single primary URL. If you have a staging domain and a production domain, create separate accounts for each.
6. Activate the AI only after the connection is confirmed. Visit or refresh your website several times, stay on the page for at least 40 seconds, and check that the SEATEXT logo shows your website name.

Verification step

1. Open browser DevTools on your live page.
2. Open the Network tab and filter for requests to your proxy or to SeaText.
3. Inspect request URLs, headers, and payloads. There should be no api key, token, or secret parameter sent from the browser.
4. Search the page source for the key. If it appears in the HTML, JavaScript, or a script tag, move it to the server.
5. Check the SeaText dashboard for your website name next to the SEATEXT logo. If it appears after five minutes, the domain is connected. If it does not appear after ten minutes, contact support.

Mistake 1: Hard-coding the API key in client-side JavaScript

The easiest way to break a secure SeaText integration is also the most common: paste the key into the script tag because it is right there in the setup instructions. That works, but anyone can view source or use DevTools to copy it. The key is no longer secret.

Use environment variables and a proxy instead. Even on a static site, you can put a tiny serverless function in front of SeaText. The function holds the key and keeps it out of the browser.

If you use a platform like WPEngine, use its custom JavaScript plugin if that is how your site is set up, but still avoid putting the key in that public code. The plugin helps you apply the snippet across pages; it does not make the key invisible.

Mistake 2: Testing on localhost or dynamic development domains

SeaText restricts development URLs like localhost for security reasons. The platform expects a valid, real domain. If you try to activate the AI on localhost, the link between traffic and your account may not work.

Dynamic development domains can also fail because SeaText may not reliably associate traffic with your account. Use a real production domain or a stable subdomain. If you need several domains, create separate accounts for each one. This is not a minor detail; the domain is part of how SeaText knows which account owns the traffic.

Mistake 3: Sharing one account across multiple websites

Each SeaText account is linked to a single primary URL. If you paste the same code on two different sites, the second site is not covered by that account. SeaText's own instructions say to create one account for each website.

From a security view, separate accounts also make a leak easier to contain. If a key for one domain leaks, the damage is limited to that domain. If you use one code everywhere, you cannot tell which site is responsible for the traffic.

Key facts at a glance

Limitations and when this advice doesn't apply

A server-side proxy is not free. It adds one more piece of infrastructure, and if the proxy is down, the page cannot reach SeaText. On a simple static site, you may need a serverless function or a proxy service.

Domain restrictions also do not hide a key. If the key is in the browser, another person can copy it and call the endpoint from anywhere. Domain binding limits where the official widget expects to run, but it is not a substitute for keeping the key on the server.

This advice applies to JavaScript integration with a website you control. It does not apply to fully managed platforms where you paste only a vendor widget and the vendor handles authentication. In that case, your job is to limit who can edit the site, rotate credentials, and check the browser console for leaks.

Terminology: the difference between the snippet, the key, and the account

The JavaScript snippet is the code you copy from SeaText. It loads the widget and starts the integration. The API key is the credential the code uses to authenticate requests. The SeaText account is the container linked to one primary URL.

Keeping these separate helps you talk about the setup with your team. The snippet can be public. The key should not be. The account tells you which domain the traffic belongs to.

FAQ

Can I keep the SeaText API key in a JavaScript file and stay safe?

No. Anything in a JavaScript file is readable by anyone. Move the key to an environment variable and make requests through your server.

Is the SeaText JavaScript integration secure by default?

The install process is secure and the AI remains inert until activated, which protects your content. It does not hide a key that you paste into public code. Use a proxy and domain separation.

Why can't I use localhost for development?

SeaText restricts development URLs such as localhost for security reasons. Use a valid real domain, and expect dynamic development domains to be unreliable.

Do I need a separate account for each website?

Yes. Each SeaText account is linked to a single primary URL, so create one account for each website.

How do I know the integration is active and linked?

Visit or refresh your site several times and stay on the page at least 40 seconds. Then wait at least five minutes and look for your website name next to the SEATEXT logo.

What should I do if the website name never appears?

Wait up to 10 minutes. If it still is not there, contact SeaText support because it may indicate an installation problem.