# Script Monitoring docs (full text)

Every page of https://docs.scriptmonitoring.com in reading order.

# Script Monitoring documentation

> Install the Script Monitoring tag, triage alerts, approve or block vendors, and collect PCI DSS 6.4.3 and 11.6.1 evidence. Guides and reference.

Source: https://docs.scriptmonitoring.com/ · Plan: All plans · Updated 2026-10-13

Script Monitoring watches every third-party script that runs on your pages. You add one script tag to the `<head>` of your site, and from then on each script your visitors load is inventoried, grouped by the vendor that serves it, and checked against a catalog of detection rules. When a rule fires you get an alert with a risk score from 1 to 10, and you decide once per vendor: allow it, block the flagged scripts, or look again later.

The same data is your evidence for PCI DSS 4.0.1: a script inventory with a justification for each vendor (requirement 6.4.3), the security headers on your payment pages watched for changes (requirement 11.6.1), and a weekly evidence pack. These docs show you how to set it up and use it. For how it works under the hood, see [How it works](https://www.scriptmonitoring.com/platform/architecture/).

## Where do I start?

  - [Quickstart](https://docs.scriptmonitoring.com/quickstart/): From install to a clean alert queue, step by step.
  - [Verify it's working](https://docs.scriptmonitoring.com/verify/): Confirm the tag is delivered and reporting.
  - [Payment pages](https://docs.scriptmonitoring.com/payment-pages/): Name the pages that take payment, for PCI DSS.
  - [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/): Block it, check where it ran, remove the source.

## Frequently asked questions

### Which plans do these docs cover?

All of them. Each page shows the lowest plan that includes the feature it describes. Plans and prices are on the [pricing page](https://www.scriptmonitoring.com/pricing/).

### Is there a version of these docs for AI assistants?

Yes. Every page has a clean Markdown version: add `.md` to its URL, or use **View as Markdown** under the title. [llms.txt](https://docs.scriptmonitoring.com/llms.txt) lists every page and [llms-full.txt](https://docs.scriptmonitoring.com/llms-full.txt) has the full text in one file.

### Where do I ask a question the docs don't answer?

Use the chat on this site or in the [dashboard](https://app.scriptmonitoring.com).

---

# Quickstart

> The shortest path to a working install: answer Setup steps 1 and 2, add the tag from step 3, load a page and confirm it reports in step 5.

Source: https://docs.scriptmonitoring.com/quickstart/ · Plan: All plans · Updated 2026-10-13

The quickest way to start is four steps in **Developers > Setup**: pick your use case, pick your site type, add the tag, and verify. Once step 5 says the tag is live, Script Monitoring is watching every third-party script on your pages.

![The Setup page for the Payments platform team: a five-step stepper (Use case, Site type, Install, Scope, Verify) with step 1 asking what you are monitoring for.](https://docs.scriptmonitoring.com/screenshots/setup-overview-light.webp)

## Step 1: open Setup

[Sign up or log in](https://app.scriptmonitoring.com). New accounts land on **Developers > Setup**.

## Step 2: answer the use case and site type

Pick **Client-side security**, **PCI DSS 6.4.3 & 11.6.1** or **Both** in step 1, and whether your site is a single-page app in step 2. They change what the install step recommends, and you can change them later. What each use case reports: [Payment pages](https://docs.scriptmonitoring.com/payment-pages/#which-use-case-should-i-choose).

## Step 3: add the tag

Copy the snippet for your method from step 3 and put it first in the `<head>` of every page: [Install the script tag](https://docs.scriptmonitoring.com/install/).

## Step 4: verify

Load a page on your site and open step 5. It says **Live** once reports arrive: [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## What's next?

[Next: Your first week →](https://docs.scriptmonitoring.com/guides/first-week/)

## Frequently asked questions

### How long does this take?

As long as it takes to deploy one line to your site. The first report arrives within a minute of a page being visited.

### Which install method should I pick?

The one that matches who owns your HTML: see [Install the script tag](https://docs.scriptmonitoring.com/install/).

## Related

- [Your first week](https://docs.scriptmonitoring.com/guides/first-week/)
- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)

---

# Install the script tag

> Add the Script Monitoring tag to your site. Copy your snippet from Setup step 3, pick a method and place the tag first in the head.

Source: https://docs.scriptmonitoring.com/install/ · Plan: All plans · Updated 2026-10-13

You install Script Monitoring by adding one script tag to the `<head>` of your site. The tag is the same for every page and every domain in a team, and the dashboard builds it for you: open **Developers > Setup**, go to step 3, **Install**, and copy the snippet for the method that fits your stack.

## Which method should I use?

Every method produces the same tag in the same place. Pick the one that matches who owns your HTML.

  - [HTML](https://docs.scriptmonitoring.com/install/html/): You edit the HTML or index.html yourself. The default and the most direct.
  - [Google Tag Manager](https://docs.scriptmonitoring.com/install/google-tag-manager/): A Custom HTML tag. For testing only, because GTM does not guarantee load order.
  - [Next.js](https://docs.scriptmonitoring.com/install/nextjs/): The @scriptmonitoring/next component, for the Pages Router or the App Router.
  - [Vite](https://docs.scriptmonitoring.com/install/vite/): The @scriptmonitoring/vite plugin injects the tag into every build.
  - [CLI](https://docs.scriptmonitoring.com/install/cli/): @scriptmonitoring/cli injects the tag into static HTML after your build step.
  - [AI assistant](https://docs.scriptmonitoring.com/install/ai-assistant/): One prompt for Claude Code, Cursor or Copilot, with your script URL in it.

> Install with AI: paste this prompt into your coding assistant: "Fetch the Script Monitoring installation guide from https://docs.scriptmonitoring.com/ai-setup.md and follow the instructions to add Script Monitoring client-side security monitoring to this project."

## How do I find my snippet?

1. In the dashboard, open **Developers > Setup**. New accounts land here after sign-up.
2. Answer step 1, **Use case**, and step 2, **Site type**. They are asked first because they change what the install step recommends, for example on a single-page app.
3. Go to step 3, **Install**, and pick a method tile: **HTML**, **GTM**, **AI**, **NextJS**, **Vite** or **CLI**.
4. Copy the snippet with its copy button. The step header shows your **Script URL**.

![The install step showing the script tag for the Payments platform team and the install method tabs: HTML, GTM, AI, NextJS, Vite and CLI.](https://docs.scriptmonitoring.com/screenshots/setup-install-snippet-light.webp)

## What goes into the snippet?

Every snippet points at your team's script URL:

```text
https://<teamID>.cdn.scriptmt.com/sm.js
```

`<teamID>` is your team's ID, a 14-digit number starting with 1: for example `https://14827391650423.cdn.scriptmt.com/sm.js`. Example IDs in these docs, such as `14827391650423`, are reserved for documentation: no real team ever gets one, and our install tools reject them. Always use your own team ID. The dashboard fills it in, so a snippet copied from Setup is ready to paste. The [CLI](https://docs.scriptmonitoring.com/install/cli/) takes the same ID as `--team-id`.

Every method produces the same tag (the plain one is on [HTML](https://docs.scriptmonitoring.com/install/html/)), with two rules:

- `referrerpolicy="origin"` sends your site's origin with the request, so the tag knows which domain it runs on. Keep it.
- There is no `async` and no `defer`. The tag has to run before the scripts it watches.

## Where on the page does the tag go?

At the top of the `<head>`, before any other script, on every page. Scripts that start before the tag are not seen. On a single-page app the rule is the same: the tag goes in the `<head>` of your HTML shell, before the app bundle, and the tag watches route changes instead of page loads.

## Do my domains need to be in the dashboard?

Yes. The tag reports from the domains in your team, so each domain it runs on must be listed under **Security > Domains**. Step 5, **Verify**, counts how many of them are reporting.

## What is under Install > Advanced?

Step 3 has an **Advanced** section with the team's install settings. Only Super admins and Admins of the team can change them.

| Setting | What it does |
| --- | --- |
| Release channel | Which web script release the tag serves: **Latest** (the default) or **Stable**. |
| Page URL query strings | Removes query strings from page URLs before they are stored. Turn it on if your URLs carry secrets, such as password reset tokens or magic links. Script URLs are not affected, and URLs already stored are unchanged. |
| Custom request headers | Headers attached to the script's requests, so you can identify and filter them. |

Some teams also see **Page monitoring scope**, a list of URL patterns that limits which pages the script monitors. With no patterns, every page is monitored.

## What comes after the install?

Set your [payment pages](https://docs.scriptmonitoring.com/payment-pages/) in step 4 if you need PCI DSS evidence, then [verify the install](https://docs.scriptmonitoring.com/verify/) in step 5. Content Security Policy reports are set up separately, with response headers on your server: see [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/).

## Frequently asked questions

### Is the snippet different for each domain?

No. The script is issued per team, and the team ID is part of its URL, so every domain in the team uses the same tag. CSP reporting is the one setting that is per domain.

### Where do I find my team ID?

The dashboard fills it in for you in Setup step 3, which shows it as **Script URL** in the step header. It is also in the **Team ID** chip in the top bar, with a copy button. A team ID is a 14-digit number starting with 1, such as `14827391650423`.

### Can I add async or defer to the tag?

No. Keep it a plain, synchronous tag at the top of the `<head>`. Scripts that run before it are not seen.

### Which method should I use for a single-page app?

The tag goes in the `<head>` of your HTML shell, before the app bundle. If you edit `index.html` yourself, use [HTML](https://docs.scriptmonitoring.com/install/html/). On Next.js, use [Next.js](https://docs.scriptmonitoring.com/install/nextjs/). To have it enforced in CI, use [Vite](https://docs.scriptmonitoring.com/install/vite/) or the [CLI](https://docs.scriptmonitoring.com/install/cli/).

### Do I need a different tag for staging?

No. The tag is per team. If staging is a separate domain, add it to the team so it reports, or put it in a separate team if you want its data kept apart (more than one team needs Pro).

## Related

- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)
- [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/)

---

# Install with an HTML script tag

> Paste the Script Monitoring script tag at the top of your site's head. Copy the snippet from Setup step 3, keep it synchronous, and add it to every page.

Source: https://docs.scriptmonitoring.com/install/html/ · Plan: All plans · Updated 2026-10-13

The HTML method is one line: paste the Script Monitoring tag at the top of the `<head>` of every page, before any other script. It works on any site where you control the HTML, including single-page apps whose `index.html` you edit yourself.

![Install with HTML: paste the script tag at the top of every page's head tag.](https://docs.scriptmonitoring.com/screenshots/setup-install-html-light.webp)

## How do I add the tag?

1. In the dashboard, open **Developers > Setup** and go to step 3, **Install**.
2. Pick **HTML**. The panel says: "Copy and paste this code at the top of your website's `<head>` tag."
3. Click **Copy script tag**. It copies just the tag:

   ```html
   <script type="text/javascript" src="https://<teamID>.cdn.scriptmt.com/sm.js" referrerpolicy="origin"></script>
   ```

4. Paste it as the first element inside `<head>` on every page:

   ```html
   <!-- index.html -->
   <!DOCTYPE html>
   <html lang="en">
     <head>
       <script type="text/javascript" src="https://<teamID>.cdn.scriptmt.com/sm.js" referrerpolicy="origin"></script>
       ...
     </head>
     <body>
     ...
     </body>
   </html>
   ```

5. Deploy, load a page on your site, and open step 5, **Verify**. See [Verify it's working](https://docs.scriptmonitoring.com/verify/).

`<teamID>` is filled in for you when you copy from the dashboard.

Before you deploy, check the tag against the [placement rules](https://docs.scriptmonitoring.com/install/#where-on-the-page-does-the-tag-go): first in the `<head>`, no `async` or `defer`, `referrerpolicy` kept. Tag managers, consent tools and analytics go below it.

**Having trouble seeing reports?**

Check the tag against the [placement rules](https://docs.scriptmonitoring.com/install/#where-on-the-page-does-the-tag-go), make sure the domain is listed under **Security > Domains**, then follow [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## What if my team uses an immutable script?

Some teams have an immutable script, turned on by Script Monitoring staff. For those teams the HTML method shows the **Immutable script** panel instead of the snippet above: a script URL that never changes, with a Subresource Integrity value.

```html
<script src="https://.../<sha256>.js" integrity="sha384-..." crossorigin="anonymous" referrerpolicy="origin"></script>
```

Copy the exact tag from the panel (**Copy script tag**, **Copy URL**, **Copy integrity**) and place it at the top of the `<head>`, synchronous, like the standard tag. Your site keeps the installed version until you replace the tag: configuration changes and script updates are adopted by installing a newly published URL and integrity value. **Refresh** only checks whether a newer version was published. It does not change your site.

## Frequently asked questions

### Do I need to change the tag when Script Monitoring ships a new script version?

No. The tag's URL serves the current release of your team's release channel (**Latest** or **Stable**, under Install > Advanced). Only an immutable script keeps the version you installed.

### Can I add it to a shared template instead of every page?

Yes. Put it in the layout or template that renders the `<head>` for every page, as the first script. On a single-page app that is the HTML shell, usually `index.html`.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Vite](https://docs.scriptmonitoring.com/install/vite/)

---

# Install with Google Tag Manager

> Add the Script Monitoring tag as a GTM Custom HTML tag on All Pages to test it quickly. For production, install the tag directly in the head.

Source: https://docs.scriptmonitoring.com/install/google-tag-manager/ · Plan: All plans · Updated 2026-10-13

You can install Script Monitoring as a Google Tag Manager **Custom HTML** tag that fires on **All Pages**. It is the fastest way to try Script Monitoring without a code change, but the dashboard marks it as for testing only: GTM does not guarantee script load order, so other scripts may run before the tag can watch them.

> **GTM installation is for testing only.** For production, add the tag directly at the top of the `<head>`. See [HTML](https://docs.scriptmonitoring.com/install/html/).

![Install with Google Tag Manager: add the tag as a Custom HTML tag that fires on all pages.](https://docs.scriptmonitoring.com/screenshots/setup-install-gtm-light.webp)

## How do I add the tag in GTM?

1. In the dashboard, open **Developers > Setup**, go to step 3, **Install**, and pick **GTM**.
2. Copy the script tag:

   ```html
   <script type="text/javascript" src="https://<teamID>.cdn.scriptmt.com/sm.js" referrerpolicy="origin"></script>
   ```

3. In [Google Tag Manager](https://tagmanager.google.com/), create a new tag of type **Custom HTML** and paste the script tag.
4. Set the trigger to **All Pages**.
5. Save and **Publish** the container.
6. Load a page on your site and open Setup step 5, **Verify**. See [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## What does GTM miss?

The GTM container itself loads as a script, and it decides when its tags run. Anything that starts before the Custom HTML tag fires, including scripts in your HTML above the container and scripts the container loads first, can run before Script Monitoring is watching. On a single-page app it is worse: the container loads after your bundle, so scripts your app injects at mount can run first.

## What should I do once testing is done?

Install the tag directly with [HTML](https://docs.scriptmonitoring.com/install/html/), [Next.js](https://docs.scriptmonitoring.com/install/nextjs/), [Vite](https://docs.scriptmonitoring.com/install/vite/) or the [CLI](https://docs.scriptmonitoring.com/install/cli/), then pause the GTM tag so the script is not loaded twice.

## Frequently asked questions

### Why is GTM only for testing?

GTM does not guarantee script load order, so other scripts may execute before Script Monitoring can watch them. For production, use direct `<script>` installation.

### Does GTM work on a single-page app?

Poorly. The container loads after your bundle, so scripts your app injects when it mounts can run before the tag is watching. Use HTML, Next.js, Vite or the CLI for production.

### How do I move from GTM to a direct install?

Add the tag to your HTML (see [HTML](https://docs.scriptmonitoring.com/install/html/)), deploy, then pause or delete the Custom HTML tag in GTM so the tag is not loaded twice.

## Related

- [HTML](https://docs.scriptmonitoring.com/install/html/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)

---

# Install in a Next.js app

> Install @scriptmonitoring/next and render ScriptMonitoringScript in pages/_document.tsx or your root layout, so the tag loads first on every page.

Source: https://docs.scriptmonitoring.com/install/nextjs/ · Plan: All plans · Updated 2026-10-13

On Next.js you install Script Monitoring with the `@scriptmonitoring/next` package: render its `ScriptMonitoringScript` component in `pages/_document.tsx` (Pages Router) or your root layout (App Router). The component renders the synchronous script tag the dashboard gives every other method, so there is no `index.html` for you to edit.

![Install with Next.js: load the tag from the root layout with next/script.](https://docs.scriptmonitoring.com/screenshots/setup-install-nextjs-light.webp)

## How do I install the package?

In the dashboard, open **Developers > Setup**, go to step 3, **Install**, and pick **NextJS**. Step 1 of the panel, **Install package**, has the command for your package manager:

```shell
npm i @scriptmonitoring/next
# or
yarn add @scriptmonitoring/next
# or
pnpm i @scriptmonitoring/next
```

## How do I add the script with the Pages Router?

Render `ScriptMonitoringScript` inside `<Head>` in `pages/_document.tsx`. This is the dashboard's **Pages Router** snippet, with your script URL filled in:

```tsx
// pages/_document.tsx

export default function Document() {
  return (
    <Html lang="en">
      <Head>
        <ScriptMonitoringScript scriptURLOverride="https://<teamID>.cdn.scriptmt.com/sm.js" /> {/* <- Here */}
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}
```

## How do I add the script with the App Router?

Render `ScriptMonitoringScript` in your root layout, before `{children}`. This is the dashboard's **App Router** snippet:

```tsx
// layout.tsx

export default function Layout({ children }) {
  return (
    <>
      <ScriptMonitoringScript scriptURLOverride="https://<teamID>.cdn.scriptmt.com/sm.js" /> {/* <- Here */}
      {children}
    </>
  );
}
```

## What does ScriptMonitoringScript render?

A plain `<script>` element with your script URL as `src`, `referrerpolicy="origin"`, and `async` and `defer` turned off. You can pass either prop:

| Prop | Value |
| --- | --- |
| `scriptURLOverride` | Your full script URL, as in the dashboard snippet. |
| `teamId` | Your team ID. Builds `https://<teamID>.cdn.scriptmt.com/sm.js`. Takes priority over `scriptURLOverride`. |

Once it is deployed, load a page and check [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## Frequently asked questions

### Should I use teamId or scriptURLOverride?

Either loads the same script. The dashboard snippet passes your full script URL as `scriptURLOverride`. `teamId="<teamID>"` builds the same `https://<teamID>.cdn.scriptmt.com/sm.js` URL, and wins if you pass both.

### Why not use next/script?

Every `next/script` strategy loads the script after the page's own scripts can start. `ScriptMonitoringScript` renders a synchronous tag instead.

### Does it work with the App Router and the Pages Router?

Yes. The dashboard has a snippet for each. Pick **Pages Router** or **App Router** in step 3.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)

---

# Install with the Vite plugin

> Install @scriptmonitoring/vite and register scriptMonitoring() in vite.config.ts. Every production build gets the tag first in the head.

Source: https://docs.scriptmonitoring.com/install/vite/ · Plan: All plans · Updated 2026-10-13

On a Vite project you install Script Monitoring as a build plugin: add `@scriptmonitoring/vite` and register `scriptMonitoring()` in `vite.config.ts`. Every production build then carries the tag at the very start of the `<head>`, so the install is enforced by your build rather than remembered by whoever edits `index.html`.

![Install with Vite: add the tag to index.html so it is the first script in the head.](https://docs.scriptmonitoring.com/screenshots/setup-install-vite-light.webp)

## How do I install the plugin?

1. In the dashboard, open **Developers > Setup**, go to step 3, **Install**, and pick **Vite**.
2. Install the package (**1. Install package**):

   ```shell
   npm i @scriptmonitoring/vite
   ```

   With yarn, `yarn add @scriptmonitoring/vite`. With pnpm, `pnpm i @scriptmonitoring/vite`.

3. Register the plugin (**2. Register the plugin**). This is the dashboard's snippet with your script URL filled in:

   ```ts
   // vite.config.ts
   import { scriptMonitoring } from '@scriptmonitoring/vite';
   import { defineConfig } from 'vite';

   export default defineConfig({
     plugins: [
       scriptMonitoring({ scriptUrl: 'https://<teamID>.cdn.scriptmt.com/sm.js' }), // <- Here
       // ...other plugins
     ],
   });
   ```

4. Build and deploy, then check [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## Which options does scriptMonitoring() take?

| Option | What it does |
| --- | --- |
| `teamId` | Your team ID. Loads `https://<teamID>.cdn.scriptmt.com/sm.js`. The recommended option. |
| `scriptUrl` | Your full script URL, as in the dashboard snippet. Deprecated: it still works, with a build warning. |
| `enabled` | Turns the plugin on or off. Defaults to off in the dev server and on in builds. |

The same configuration with `teamId`:

```ts
// vite.config.ts

export default defineConfig({
  plugins: [scriptMonitoring({ teamId: '<teamID>' })],
});
```

## Why don't I see the tag in development?

The plugin skips the dev server unless you pass `enabled: true`, and logs "[Script Monitoring] Plugin is disabled (because you are in development mode)". Check the built `dist/index.html` instead: the first element in `<head>` is the Script Monitoring tag.

## Frequently asked questions

### Why is the tag missing when I run the dev server?

The plugin is off in the Vite dev server by default and logs a warning saying so. It runs in production builds. Pass `enabled: true` to turn it on in development too.

### Should I use scriptUrl or teamId?

The dashboard snippet passes `scriptUrl`. The package now marks `scriptUrl` as deprecated in favor of `teamId`, and prints a warning at build time when you use it. `scriptMonitoring({ teamId: '<teamID>' })` loads the same script without the warning.

### Where does the plugin put the tag?

At the very start of the `<head>` (`head-prepend`), with `referrerpolicy="origin"`, in every HTML file Vite builds.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [CLI](https://docs.scriptmonitoring.com/install/cli/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)

---

# Install with the CLI

> Run npx @scriptmonitoring/cli after your build to inject the Script Monitoring tag into every static HTML file. Works for dist and .next output and in CI.

Source: https://docs.scriptmonitoring.com/install/cli/ · Plan: All plans · Updated 2026-10-13

The Script Monitoring CLI injects the tag into your static HTML after your build: run `npx @scriptmonitoring/cli@latest --team-id <teamID>` as the last step of your build or CI job. It suits static sites and any build you would rather not change, and it keeps the tag in place without anyone editing HTML by hand.

![Install with the CLI: one command that detects your framework and adds the tag.](https://docs.scriptmonitoring.com/screenshots/setup-install-cli-light.webp)

## How do I run it?

1. In the dashboard, open **Developers > Setup**, go to step 3, **Install**, and pick **CLI**. The panel says: "Inject the Script Monitoring script into your static HTML build output. Run this after your build step."
2. Copy the command. Your team ID is already in it:

   ```shell
   # Run after your build step
   npm_config_yes=true npx @scriptmonitoring/cli@latest --team-id <teamID>

   # Or specify a directory
   npm_config_yes=true npx @scriptmonitoring/cli@latest --team-id <teamID> --dir ./dist
   ```

3. Add it to your build, after the step that writes your HTML. For example, in `package.json`:

   ```json
   {
     "scripts": {
       "build": "vite build && npm_config_yes=true npx @scriptmonitoring/cli@latest --team-id <teamID>"
     }
   }
   ```

4. Deploy the processed files and check [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## Which options does the CLI take?

| Option | What it does |
| --- | --- |
| `--team-id`, `-t` | Your team ID. Builds the script URL `https://<teamID>.cdn.scriptmt.com/sm.js`. |
| `--dir`, `-d` | The folder (or single HTML file) to process. Defaults to `dist`, then `.next`. |
| `--silent`, `-s` | Stops the CLI from listing each processed file. |

Run `npx @scriptmonitoring/cli --help` for the full list.

## What does it change in my HTML?

In every HTML file it finds (skipping `node_modules` and `vendor`), the CLI removes any existing Script Monitoring tag and inserts the current one before the first `<link>` or `<script>`:

```html
<script src="https://<teamID>.cdn.scriptmt.com/sm.js" referrerpolicy="origin" data-src="..."></script>
```

## Frequently asked questions

### Which folder does the CLI process?

By default it looks for `dist`, then `.next`, in the current directory. Pass `--dir` (or `-d`) to point it at another folder or a single HTML file.

### Is it safe to run twice?

Yes. Before injecting, the CLI removes any Script Monitoring tag it finds, so a second run leaves one tag, not two.

### Where in the HTML does it put the tag?

Right before the first `<link>` or `<script>` tag in each file, with `referrerpolicy="origin"`.

### What does npm_config_yes=true do?

It answers yes to npx's install prompt, so the command runs unattended in CI.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Vite](https://docs.scriptmonitoring.com/install/vite/)

---

# Install with an AI coding assistant

> Paste one prompt into Claude Code, Cursor or GitHub Copilot. It fetches the Script Monitoring setup guide and installs the tag with your script URL.

Source: https://docs.scriptmonitoring.com/install/ai-assistant/ · Plan: All plans · Updated 2026-10-13

You can let an AI coding assistant install Script Monitoring: copy the prompt from **Developers > Setup**, step 3, **AI**, and paste it into Claude Code, Cursor, GitHub Copilot or a similar tool. The prompt tells the assistant to fetch our setup guide, detect your framework and add the tag with your team's script URL.

![Install with an AI assistant: a ready-made prompt for your coding assistant that adds the tag to your codebase.](https://docs.scriptmonitoring.com/screenshots/setup-install-ai-light.webp)

> Install with AI: paste this prompt into your coding assistant: "Fetch the Script Monitoring installation guide from https://docs.scriptmonitoring.com/ai-setup.md and follow the instructions to add Script Monitoring client-side security monitoring to this project."

## What is the prompt?

The **AI** panel says: "Paste this prompt into your AI coding assistant (Claude Code, Cursor, GitHub Copilot, etc.) to install Script Monitoring in your project." **Copy prompt** copies one line, with your script URL filled in:

```text
Fetch the Script Monitoring installation guide from https://docs.scriptmonitoring.com/ai-setup.md and follow the instructions to add Script Monitoring client-side security monitoring to this project. Use this script URL: https://<teamID>.cdn.scriptmt.com/sm.js
```

## How do I use it?

1. In the dashboard, open **Developers > Setup**, go to step 3, **Install**, and pick **AI**.
2. Click **Copy prompt**.
3. Open your project in your coding assistant and paste the prompt.
4. Review the change before you merge it:
   - the tag (or `ScriptMonitoringScript`, or the `scriptMonitoring()` plugin) is the first script in the `<head>`, with no `async` or `defer`;
   - nothing else in the `<head>` was removed or reordered;
   - if the project has a Content Security Policy, `*.cdn.scriptmt.com` was added to the existing `script-src` and `connect-src`, and nothing was removed.
5. Deploy, load a page and check [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## What does the setup guide tell the assistant?

[ai-setup.md](https://docs.scriptmonitoring.com/ai-setup.md) is plain Markdown written for coding assistants. First it makes the assistant use your real script URL: it takes it from the prompt, asks you for it (or your team ID from **Developers > Setup**) if it is missing, never guesses one, and checks that the URL returns the script before it changes any file. Then it asks the assistant to pick the method that fits the project ([Next.js](https://docs.scriptmonitoring.com/install/nextjs/), [Vite](https://docs.scriptmonitoring.com/install/vite/), the [CLI](https://docs.scriptmonitoring.com/install/cli/) for static builds, or [HTML](https://docs.scriptmonitoring.com/install/html/)), keep the tag first and synchronous, add it only once, and extend an existing Content Security Policy instead of replacing it.

## Frequently asked questions

### What does the assistant read?

The prompt points it at [ai-setup.md](https://docs.scriptmonitoring.com/ai-setup.md), a Markdown guide written for coding assistants. It covers Next.js, Vite, static builds with the CLI, plain HTML and Content Security Policy changes.

### Does the prompt contain anything secret?

No. It contains your team's script URL, which is public: every visitor's browser loads it.

### Which assistants does it work with?

Any assistant that can fetch a URL and edit your project, such as Claude Code, Cursor or GitHub Copilot. If yours cannot fetch URLs, paste the contents of [ai-setup.md](https://docs.scriptmonitoring.com/ai-setup.md) along with your script URL.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)

---

# Verify it's working

> Check that the Script Monitoring tag is delivered and reporting: read Setup step 5, Verify, its tiles, per-domain list and status notes.

Source: https://docs.scriptmonitoring.com/verify/ · Plan: All plans · Updated 2026-10-13

To confirm Script Monitoring is working, open **Developers > Setup** and go to step 5, **Verify**: it shows how often the tag was delivered this month and which domains sent script reports in the last 24 hours. Once the install is running, [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/) watches every data stream and flags any that go quiet.

## How do I check the install in Setup?

1. Load a page on your site that has the tag.
2. In the dashboard, open **Developers > Setup** and go to step 5, **Verify**.
3. Read the **Activation** card. Its tiles:

   | Tile | What it counts |
   | --- | --- |
   | Delivered | Tag requests served this month. |
   | Reporting | How many of your team's domains sent script reports in the last 24 hours, for example "2 of 3". |
   | Received | Script reports that landed in the last 24 hours. |
   | PCI scope | Your payment page selectors. Shown when the use case is **Both**. |

4. Check each row in the **Per-domain** list. A domain that reports says **Receiving**, with "first report" and a date. Agentic crawler domains say **Crawled**.

![The Verify step of Setup confirming the tag is live on both Payments platform domains.](https://docs.scriptmonitoring.com/screenshots/setup-verify-light.webp)

## What does each status note mean?

Step 5 shows one note, the first that applies:

| Note | Meaning |
| --- | --- |
| **Setup is not complete.** | Your use case needs payment pages, but step 4 has none. Nothing is in PCI scope until you add one. |
| **Delivered, but never activated.** | The tag was served this month and no script report landed in 24 hours. Check that the tag is in the served HTML. On a single-page app, test a real URL in step 4. |
| **Live, narrowly.** | Reports are arriving, and only payment pages report. A low count is expected: the tag ships everywhere and reports only from checkout. |
| **Live across the site.** | Reports are arriving from your domains. |
| **Nothing has arrived yet.** | No report yet. Once a page with the tag is visited, the first report lands within a minute. |

## What comes next?

Click **Done, go to Diagnostics** to watch the install over time: see [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/).

## Frequently asked questions

### How long until the first report shows up?

Within a minute of a page with the tag being visited. Step 5 says "Nothing has arrived yet" until then.

### Step 5 says "Delivered, but never activated". What does that mean?

The tag was served this month but no script report landed in the last 24 hours. Check that the tag is in the HTML your server actually sends, as the first script in the `<head>`. On a single-page app this usually means a payment page selector does not describe the route your router produces: test a real URL in step 4.

### Does Verify keep checking after setup?

Step 5 always shows the last 24 hours, so you can come back to it. For ongoing monitoring of every stream, use [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/).

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/)
- [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/)

---

# Payment pages

> Tell Script Monitoring which pages take payment with selectors in Setup step 4, test a real checkout URL, and choose whether only payment pages report.

Source: https://docs.scriptmonitoring.com/payment-pages/ · Plan: All plans · Updated 2026-10-13

Payment pages are the pages where card data is entered. You list them once, as URL selectors in **Developers > Setup**, step 4, **Scope**, and that one list decides both what counts as a payment page for the tag and what a PCI DSS report counts as one, so the two cannot drift apart. Script Monitoring needs them for PCI DSS 6.4.3 and 11.6.1 evidence. For security monitoring alone, every page reports and there is nothing to set.

## Which use case should I choose?

The use case in step 1 decides how much of your site reports. You can change it later without reinstalling.

| Use case | What reports | Payment pages |
| --- | --- | --- |
| Client-side security | Every page. You see every third-party script, everywhere. | Not needed. |
| PCI DSS 6.4.3 & 11.6.1 | Only payment pages, once you turn on **Only payment pages report**. The tag still ships on every page. | Required. |
| Both | Every page, and your payment pages are also tracked as a named PCI scope. | Required. |

![Setup step 1, Use case: choose Client-side security, PCI DSS 6.4.3 & 11.6.1, or Both.](https://docs.scriptmonitoring.com/screenshots/setup-step-1-light.webp)

**PCI DSS** alone is the narrow setting: nothing outside checkout is inventoried, so Vendors, Alerts and Blocks only show what runs on a payment page. Pick **Both** if you also want cover on the rest of the site.

## How do I add a payment page?

1. Open **Developers > Setup** and go to step 4, **Scope**.
2. Under **Payment page selectors**, type a selector and click **Add selector**. A path such as `/checkout` applies to every domain in the team.
3. Add one selector per checkout route. Each appears as a chip; click its **x** to remove it.

Some teams see their domains as tabs in this step, each with its own list of paths, and an **Import CSV** button that replaces each listed domain's payment pages with the ones in the file. The selectors work the same way.

![Payment page selectors for checkout.northwind.com: /checkout and /checkout/:step, where :name matches one path segment and * matches anything.](https://docs.scriptmonitoring.com/screenshots/setup-payment-pages-light.webp)

## How do I write a selector?

Selectors are URL patterns, matched with the same matcher the tag uses:

| Selector | Matches |
| --- | --- |
| `/checkout` | `/checkout` on every domain in the team. |
| `/checkout/:step` | `/checkout/payment`, `/checkout/review`: `:name` matches one path segment. |
| `/pay/*` | Anything under `/pay/`: `*` matches anything in a segment. |
| `shop.example.com/checkout` | `/checkout` on that host only. |
| `/#/checkout` | A single-page app route after the `#` (fragment routing). |

- Query strings are stripped before matching. A selector with `?` in it can never match.
- The protocol and port do not matter, and a trailing slash is optional.
- A selector can be up to 512 characters, and a team can have up to 500.

## How do I check a selector before relying on it?

Use **Test a real URL** under the selectors. Paste a real checkout URL, for example `https://checkout.example.com/checkout/payment`:

- **Matches**: "A visit to this URL is monitored and counts as a payment page in your PCI evidence." The note names the selectors that matched.
- **No match**: the page is not a payment page. It is still monitored, but does not count in your PCI evidence. If only payment pages report, it would be delivered but never monitored.

On a single-page app, a miss here is the most common setup mistake: make sure the selector describes the route your router actually produces.

## What warnings can Scope show?

| Warning | What to do |
| --- | --- |
| No payment page defined | Your use case is PCI DSS or Both and there is no selector. Without one, 6.4.3 has no inventory and 11.6.1 has no page to watch, and it looks the same as a quiet week. Add a selector. |
| No domain here is marked as taking payment | Selectors exist, but none matches a domain in this team. Add a selector for the host that takes payment. |
| Fragment routing, but a selector has no fragment | Your site routes with `#/`. Write `/#/checkout`, not `/checkout`. |
| Path routing, but a selector uses a fragment | Remove the `#`, or switch the site to fragment routing in step 2. |
| A selector contains a query string | Query strings are removed before matching. Scope on the path. |

## What does "Only payment pages report" do?

With the **PCI DSS 6.4.3 & 11.6.1** use case, the **Only payment pages report** switch narrows reporting to your selectors. On every page no selector matches, Script Monitoring stops:

- inventorying the scripts that run there,
- alerting on new or changed scripts there,
- collecting the evidence that blocking and the Vendors, Alerts and Blocks pages rely on there.

The tag keeps loading on every page. Turn the switch off at any time and every page reports again.

Its guards:

- It is available only after a selector has matched a real page in the last 7 days. Until then it says "Available once a selector matches a real page in the last 7 days."
- Turning it on asks you to confirm. Turning it off is one click.
- Setup never turns it on by itself. Switching the use case to **Client-side security** or **Both** turns it off.
- If an edit leaves no usable selector, it switches off and Scope says so: "Only payment pages report was turned off."

Super admins and Admins of the team can change it and edit selectors. Viewers cannot.

## Where else are payment pages shown?

The **Payment pages monitored** tab of the PCI DSS page lists every page in scope and the pages no selector covers: see [PCI DSS 6.4.3 & 11.6.1](https://docs.scriptmonitoring.com/pci-dss/#what-does-the-payment-pages-monitored-tab-show).

## Frequently asked questions

### Do I need payment pages if I only want security monitoring?

No. With **Client-side security** every page reports and there is nothing to configure in step 4. Payment pages are needed for PCI DSS 6.4.3 and 11.6.1 evidence, so pick **Both** if an assessor is going to ask.

### Why can't I turn on "Only payment pages report"?

It becomes available once one of your selectors has matched a real page in the last 7 days. It is only offered with the **PCI DSS 6.4.3 & 11.6.1** use case.

### Does "Only payment pages report" remove the tag from other pages?

No. The tag keeps loading on every page. Pages that no selector matches stop sending anything, so they are not inventoried, not alerted on, and not counted as evidence.

### My checkout is a single-page app with routes after a #. What do I type?

Write the fragment into the selector, such as `/#/checkout`. With fragment routing the path is `/` on every route, so `/checkout` never matches.

### Do query strings matter?

No. Query strings are stripped before matching, so anything after `?` in a selector can never match. Scope on the path instead.

## Related

- [PCI DSS 6.4.3 & 11.6.1](https://docs.scriptmonitoring.com/pci-dss/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Install the script tag](https://docs.scriptmonitoring.com/install/)

---

# CSP reporting

> Send Content Security Policy violation reports to Script Monitoring. Add the headers from the CSP setup sheet, then run the header check.

Source: https://docs.scriptmonitoring.com/csp-reporting/ · Plan: All plans · Updated 2026-10-13

Content Security Policy (CSP) violation reports come from your server's response headers, not from the Script Monitoring tag. You add a report-only policy, or two reporting directives to the policy you already send, and browsers then report every violation to Script Monitoring. The dashboard's **Set up CSP reporting** sheet generates the exact headers for each domain and checks that they are live.

CSP reporting is on every plan. The number of reports shown each month depends on the plan: 50,000 on Free, 1,000,000 on Pro and 2,000,000 on Enterprise. Reports beyond the limit are still collected, just not shown.

## How do I open the CSP setup sheet?

From either of these:

- **Developers > Setup**, step 3, **Install**: under **CSP reporting**, click **Set up CSP reporting**.
- **Security > CSP violations**: click **Set up CSP reporting**, **Set up this domain** or **Set up another domain**.

The sheet has four steps: **Choose domains**, **Add the headers**, **Check the headers** and **Done**.

![The Set up CSP reporting sheet, step 1 of 4: choose the domains you will add the reporting headers to. checkout.northwind.com is already reporting; pay.northwind.com is not set up.](https://docs.scriptmonitoring.com/screenshots/setup-csp-sheet-light.webp)

## How do I add the headers?

1. **Choose domains.** Pick the domains you will add the headers to. Each shows **Reporting** or **Not set up**. The domain in the top bar is picked for you.
2. **Add the headers.** Answer "Does the site already send a Content-Security-Policy header?":
   - **No CSP yet**: add a report-only policy. It reports and never blocks.
   - **Already has a CSP**: add the reporting directives to the policy you send.
3. Copy each header with its **Copy** button. With several domains, use the domain tabs: every domain has its own endpoint.
4. Add the headers to the responses your server sends for every page, and deploy.
5. Click **I added them, check now**.

![CSP reporting step 2 of 4: the Content-Security-Policy-Report-Only, Reporting-Endpoints and Report-To headers to add to pay.northwind.com, each with a Copy button.](https://docs.scriptmonitoring.com/screenshots/setup-csp-sheet-headers-light.webp)

## Which headers does Script Monitoring generate?

For a site with **no CSP yet**, three headers. `<endpoint>` is the domain's own reporting endpoint, filled in by the sheet:

```http
Content-Security-Policy-Report-Only: default-src 'self'; report-uri <endpoint>; report-to csp-endpoint;
Reporting-Endpoints: csp-endpoint="<endpoint>"
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"<endpoint>"}]}
```

For a site that **already has a CSP**, append two directives to the policy you send. Nothing else in it changes:

```text
report-uri <endpoint>; report-to csp-endpoint;
```

and add the same `Reporting-Endpoints` and `Report-To` headers. `Report-To` is for older browsers, which read it instead of `Reporting-Endpoints`.

The endpoint is on `csp.scriptmt.com`:

| Domain type | Endpoint |
| --- | --- |
| Script tag domain | `https://csp.scriptmt.com/csp` |
| Agentic crawler domain | `https://csp.scriptmt.com/csp/<domainID>` |

Always copy the endpoint from the sheet. Reports sent to the wrong endpoint are discarded.

## What do the check results mean?

![CSP reporting step 3 of 4: Script Monitoring loaded pay.northwind.com and found the reporting headers.](https://docs.scriptmonitoring.com/screenshots/setup-csp-sheet-check-light.webp)

**Check the headers** loads each domain and reads its headers. A change can take a few minutes to reach your site; click **Check again** to rerun.

| Result | Meaning and fix |
| --- | --- |
| Reporting correctly | The policy reports to Script Monitoring. The domain is set up. |
| Not reporting to us | A policy was found, but it does not report to this domain's endpoint. Add `report-uri` and `report-to`. |
| Policy in a meta tag | The policy is in a `<meta>` tag, which cannot send reports. Send it as a header. |
| No CSP found | No Content-Security-Policy header was found. Deploy the headers, then check again. |
| Could not check | The check could not run, for example because the domain could not be reached. Try again in a moment. |

You can continue with **Continue anyway** if some domains are not ready. The **Done** step lists them with "Check again later", and you can rerun the check from **Security > CSP violations**.

## Where do the reports show up?

Violations appear on **Security > CSP violations** within a few minutes, and the **CSP Violations** stream on [Diagnostics](https://docs.scriptmonitoring.com/verify/) turns to **Receiving**.

## Frequently asked questions

### Why can't the script tag send CSP reports?

Browsers only send Content Security Policy reports for policies delivered in response headers. The policy and its reporting directives have to come from your server, so CSP reporting is set up separately from the tag.

### Will the report-only policy block anything?

No. `Content-Security-Policy-Report-Only` reports what the policy would block and never blocks. The setup sheet never offers an enforcing starter policy.

### Can I put the policy in a meta tag?

A policy in a `<meta>` tag cannot send reports, so the check returns "Policy in a meta tag". Send it as a response header.

### Why is the endpoint different for each domain?

Reports are matched to a domain by the endpoint they are sent to, and reports sent to another domain's endpoint are discarded. Copy the headers for each domain from the sheet instead of reusing one domain's headers.

### Does my existing CSP need to allow Script Monitoring's own script?

If your `script-src` or `connect-src` lists specific hosts, add `*.cdn.scriptmt.com` to both, so the tag can load and send its findings.

## Related

- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Install the script tag](https://docs.scriptmonitoring.com/install/)

---

# Your first week

> A day-by-day plan after install: set payment pages and CSP, clear the alert queue, decide on every vendor, then turn on notifications and invite your team.

Source: https://docs.scriptmonitoring.com/guides/first-week/ · Plan: All plans · Updated 2026-10-13

Your first week takes a freshly installed team to a calm dashboard: every alert decided, every vendor allowed or blocked, and the right people notified. Each day is one short session that points to the guide for it. Start once the tag is installed and reporting: if it is not yet, do the [Quickstart](https://docs.scriptmonitoring.com/quickstart/) first.

![Home for Payments platform: 1 critical alert on checkout.northwind.com, tiles for open alerts, vendors, scripts seen, payment pages, active blocks and quiet streams, and the top risks ranked by score.](https://docs.scriptmonitoring.com/screenshots/home-light.webp)

## Day 1: payment pages and CSP

If you need PCI DSS evidence, name your payment pages in Setup step 4: [Payment pages](https://docs.scriptmonitoring.com/payment-pages/). For Content Security Policy reports, add the headers from the CSP setup sheet: [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/).

## Day 2: clear the alert queue

Start with **Needs action** in **Security > Alerts** and decide each vendor: [Triage alerts](https://docs.scriptmonitoring.com/guides/triage-alerts/). If a script should not be there at all, follow [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/).

![The decision queue: n0rthwind.com Critical (payment skimmer found on the page), Google Tag Manager High, Klaviyo High, Intercom Medium and Cloudflare Low.](https://docs.scriptmonitoring.com/screenshots/alerts-queue-light.webp)

## Day 3: decide on your vendors

Home's **Vendors** tile counts the vendors nobody has decided on yet. Allow or block each one: [Approve or block a vendor](https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/). For PCI DSS, also justify each payment-page vendor: [Prepare PCI DSS evidence](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/).

## Day 4: notifications and your team

Check which rules your use case turned on and add destinations: [Set up notifications](https://docs.scriptmonitoring.com/guides/notifications/). Invite the people who act on alerts under **Settings > Members**.

## What does a good end of week look like?

On **Home**:

- **Open alerts** and **Need action** are at or near zero, and there is no critical banner.
- **Vendors** shows "0 not reviewed".
- **Quiet streams** says "All reporting".
- **Active blocks** counts the block rules you chose to keep.

## Frequently asked questions

### Why is the alert queue long on the first day?

Everything on your pages is new to Script Monitoring at first. Decisions are one per vendor, so a long list of alerts usually comes down to a handful of decisions.

### Do I have to follow the days in order?

No. Each day is one short session. Home shows where you are, and every number on it opens the list behind it.

## Related

- [Quickstart](https://docs.scriptmonitoring.com/quickstart/)
- [Triage alerts](https://docs.scriptmonitoring.com/guides/triage-alerts/)
- [Set up notifications](https://docs.scriptmonitoring.com/guides/notifications/)

---

# Triage alerts

> Clear the Alerts queue one vendor at a time: start with Needs action, open each decision, then Allow, Block or choose Not now. Keyboard shortcuts included.

Source: https://docs.scriptmonitoring.com/guides/triage-alerts/ · Plan: All plans · Updated 2026-10-13

To triage alerts, work through **Security > Alerts** one vendor at a time, starting with the critical and high decisions. Each decision takes one click: **Allow**, **Block** or **Not now**. What the score and each action mean is on the [Alerts reference](https://docs.scriptmonitoring.com/alerts/).

![The decision queue: n0rthwind.com Critical (payment skimmer found on the page), Google Tag Manager High, Klaviyo High, Intercom Medium and Cloudflare Low.](https://docs.scriptmonitoring.com/screenshots/alerts-queue-light.webp)

## How do I work through the queue?

1. Open **Security > Alerts**. The subtitle says how many open alerts there are in the top bar's date range and how many decisions they make.
2. Click **Needs action** to see critical and high decisions first. The other chips filter by band: **Critical**, **High**, **Medium**, **Low**.
3. Open a row (click it, or press Enter or O). The side sheet lists every open alert for the vendor: what happened, the script URL, why the rule fired, the rule name and score, the domain and when.
4. Decide:
   - **Allow** if the behavior is expected from this vendor.
   - **Block** if a flagged script should not run on your site.
   - **Not now** if you need to check with someone first.
5. Repeat until the page says **Queue clear**.

![The review sheet for n0rthwind.com: 10.0 Critical, why it scored 10.0 (Payment Skimmer, Script Monitoring Watchlist Match, Keylogger or Form Data Stealer), the load chain through Google Tag Manager, the PCI DSS 4.0.1 compliance gap and the pages it was seen on, with Not now, Allow and Block.](https://docs.scriptmonitoring.com/screenshots/alert-review-sheet-light.webp)

Keyboard: **J** and **K** move, **X** selects, **A** allows, **B** blocks, **I** is Not now. Select several rows to use **Allow all**, **Block all** or **Not now** in the bar at the bottom.

## What if I'm not sure yet?

Choose **Not now**. The decision moves to **Suppressed** at the bottom of the page and comes back in 7 days, or earlier if the vendor raises a new alert. **Bring back** returns it to the queue now.

![Suppressed decisions: vendors that were scored and cleared or snoozed with Not now. They are never hidden.](https://docs.scriptmonitoring.com/screenshots/alerts-suppressed-light.webp)

## What if the script is malicious?

Block it from the decision, then follow [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/).

## Frequently asked questions

### I can't click Allow or Block. Why?

Only Super admins and Admins can allow, block and snooze. Viewers see the queue with a note saying so.

### A decision I put on Not now came back early. Why?

A new alert fired for that vendor. Not now lasts 7 days or until the vendor raises a new alert, whichever comes first.

### Can I undo a decision?

Yes. Allow and Block each show **Undo** in their toast. Undoing keeps the alerts resolved; the vendor needs review again, or its scripts load again.

## Related

- [Alerts (reference)](https://docs.scriptmonitoring.com/alerts/)
- [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/)
- [Approve or block a vendor](https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/)

---

# Respond to a malicious script

> What to do when Script Monitoring flags a malicious script: block it at the edge, check which pages it ran on, confirm the block and remove the source.

Source: https://docs.scriptmonitoring.com/guides/malicious-script/ · Plan: All plans · Updated 2026-10-13

When Script Monitoring flags a malicious script, block it first and investigate second. A block from the alert stops the flagged scripts on every domain in your team in under 60 seconds, at the Script Monitoring edge, without a deploy on your side. Each step below links to the page that explains it.

![The review sheet for n0rthwind.com: 10.0 Critical, why it scored 10.0 (Payment Skimmer, Script Monitoring Watchlist Match, Keylogger or Form Data Stealer), the load chain through Google Tag Manager, the PCI DSS 4.0.1 compliance gap and the pages it was seen on, with Not now, Allow and Block.](https://docs.scriptmonitoring.com/screenshots/alert-review-sheet-light.webp)

## Step 1: block it from the alert

Open **Security > Alerts**, click **Critical** and open the decision. Read what happened and the script URL, then click **Block** and **Block now**. How the score and the three actions work: [Alerts](https://docs.scriptmonitoring.com/alerts/).

## Step 2: check where it ran

Open the vendor's details from the alert or from **Security > Vendors**. **Seen pages** marks each page as **Payment page** or **Not a payment page**, and the **PCI DSS 4.0.1** section says whether it ran in scope: [Vendors](https://docs.scriptmonitoring.com/vendors/).

## Step 3: confirm the block

On **Security > Blocks**, the rule says **Blocking** once it has stopped a request: [Blocks](https://docs.scriptmonitoring.com/blocks/).

## Step 4: remove the source

A block stops the script from loading through Script Monitoring. Also remove the cause from your site: the tag, the compromised dependency or the tag manager entry that injects it. Keep the block until you are sure the source is gone, then lift it from **Security > Blocks**.

## Frequently asked questions

### What if the script has no alert?

Add a block rule yourself on **Security > Blocks** with **Block a script**: see [Blocks](https://docs.scriptmonitoring.com/blocks/).

### Who needs to know?

If the script ran on a payment page, involve whoever owns your PCI DSS incident response. The **Malicious script detected** notification can alert your team as soon as the rule fires: see [Notifications](https://docs.scriptmonitoring.com/notifications/).

## Related

- [Alerts](https://docs.scriptmonitoring.com/alerts/)
- [Blocks](https://docs.scriptmonitoring.com/blocks/)
- [Vendors](https://docs.scriptmonitoring.com/vendors/)

---

# Approve or block a vendor

> Review a vendor on the Vendors page, read its score, pages and PCI DSS status, then Allow it as approved or Block every resource it serves.

Source: https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/ · Plan: All plans · Updated 2026-10-13

To decide on a vendor, open it from **Security > Vendors**, check what it does and where it runs, then **Allow** or **Block** it. One decision covers the whole vendor, and Alerts and your PCI DSS evidence use it. What each status and field means is on the [Vendors reference](https://docs.scriptmonitoring.com/vendors/).

## How do I review a vendor?

1. Open **Security > Vendors**. Search with **Search vendors…**, pick a category, or look for **Needs review** badges.
2. Click the row to open its details.
3. Check **Why it scored**, **Seen pages** (is it on a payment page?) and **What it does on the page**.
4. Decide:
   - **Allow** if you expect it on your site. The toast has **Undo**.
   - **Block** if you don't want it on your site at all. Enter a reason under **Provide reason** and click **Block**.

![The Klaviyo vendor sheet: 7.0 High, loaded by Google Tag Manager on pay.northwind.com, in PCI scope with a compliance gap, the pages it was seen on, and what it does (JavaScript, storage, form field access).](https://docs.scriptmonitoring.com/screenshots/vendor-review-sheet-light.webp)

## What if it runs on a payment page?

Approving it for PCI DSS also needs a written justification on the Compliance page: see [Prepare PCI DSS evidence](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/).

## Frequently asked questions

### Should I allow from Alerts or from Vendors?

If the vendor has open alerts, allow it from **Security > Alerts**: that also resolves the alerts. From Vendors, Allow approves the vendor, and it turns **Approved** once it has no open alerts.

### I want to stop only one script, not the whole vendor.

Block from the alert, or add a rule for that script URL on [Blocks](https://docs.scriptmonitoring.com/blocks/).

### How do I start a vendor's review over?

Use the row's menu (**…**) and **Reset reviewed permissions**.

## Related

- [Vendors (reference)](https://docs.scriptmonitoring.com/vendors/)
- [Triage alerts](https://docs.scriptmonitoring.com/guides/triage-alerts/)
- [Prepare PCI DSS evidence](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/)

---

# Prepare PCI DSS evidence

> Get assessor-ready evidence from Script Monitoring: justify payment-page vendors, check header changes and generate the weekly report.

Source: https://docs.scriptmonitoring.com/guides/pci-dss-evidence/ · Plan: All plans · Updated 2026-10-13

To prepare your PCI DSS 6.4.3 and 11.6.1 evidence, confirm your payment pages are in scope, justify every payment-page vendor, review the week's security header changes, and generate the evidence pack. All four steps happen under **Compliance > PCI DSS 6.4.3 & 11.6.1**; what each tab shows is on the [PCI DSS reference](https://docs.scriptmonitoring.com/pci-dss/).

For what the requirements ask and how assessors test them, see [requirement 6.4.3](https://www.scriptmonitoring.com/pci-dss-6-4-3/) and [requirement 11.6.1](https://www.scriptmonitoring.com/pci-dss-11-6-1/). This page covers the steps in the dashboard.

## What do I need before I start?

- The tag installed and reporting. See [Verify it's working](https://docs.scriptmonitoring.com/verify/).
- The use case **PCI DSS 6.4.3 & 11.6.1** or **Both**, and your [payment pages](https://docs.scriptmonitoring.com/payment-pages/) named in Setup step 4.

The page follows the top bar's domain and date range. A PCI view covers at most 10 days at a time.

## Step 1: are all my payment pages in scope?

Open the **Payment pages monitored** tab. It lists every page Script Monitoring treats as a payment page and the selector that put it there. This is the scope both 6.4.3 and 11.6.1 are measured against.

![PCI DSS, Payment pages monitored: the pages in scope, the selector that matched each one, scripts and script loads per page, and pages seen on a payment domain but not in scope.](https://docs.scriptmonitoring.com/screenshots/pci-pages-light.webp)

1. Check **Pages in scope** and **Selectors**. A selector that matches nothing is the same as having no selector at all.
2. Under **Seen but not in scope**, click **Add to scope** for each page that takes card data, or confirm it takes none.
3. To change the selectors, click **Edit scope in Setup**: see [Payment pages](https://docs.scriptmonitoring.com/payment-pages/).

## Step 2: is every vendor justified? (6.4.3)

Open the **Vendors** tab. The tab shows a count of vendors needing review.

![PCI DSS, Vendors (6.4.3): every vendor on a payment page with its justification, category, last seen date and status: Approved or Needs review.](https://docs.scriptmonitoring.com/screenshots/pci-vendors-light.webp)

1. Filter on **Needs review**.
2. Open a vendor with its eye button. The review sheet lists its scripts and alerts.
3. Write a **Justification**: why the script is on your payment page and what it is allowed to do. **Use AI Suggestion** fills in a draft when the AI review is available on your plan.
4. Click **Submit** (or **Submit and next**) to approve it. To refuse it, click **Block**. **Ignore** hides a vendor from PCI review and reports; it needs a justification too.

Rules to know:

- A vendor with open alerts cannot be approved until the alerts are resolved. You can still block it.
- A script can carry its own justification that overrides the vendor's. Use **Override justification for this script** on the **Scripts** tab.
- On Pro and Enterprise, **AI auto-approval for PCI DSS** drafts a justification for each vendor and approves the ones it can justify. With it off, vendors wait for your review with the AI's suggestion in the sheet.

## Step 3: what changed in the headers? (11.6.1)

Open the **Headers** tab. It shows the latest week inside your date range.

![PCI DSS, Headers (11.6.1): a change calendar of security headers on payment pages over the week and the list of header changes.](https://docs.scriptmonitoring.com/screenshots/pci-headers-light.webp)

1. In the **Change calendar**, look for amber cells: a day a header value changed.
2. Read each change in **Security header changes**.
3. Check every change against a planned release. An unexplained change on a payment page is what 11.6.1 asks you to detect and act on.

## Step 4: how do I produce the report?

Open the **Reports** tab. **Weekly evidence packs** lists the packs on file.

![PCI DSS, Reports: weekly evidence packs with the vendors needing action and header changes each week, all Ready to download.](https://docs.scriptmonitoring.com/screenshots/pci-reports-light.webp)

1. Click **Generate now**.
2. Pick a **Domain** and click **Generate report**. Only domains with PCI DSS set up are listed.
3. Wait for the status to change from **Generating** to **Ready**, usually within a few minutes. You also get an email with a link.
4. Click **PDF** to open the report, then **Print / Save as PDF** to save a copy.

### What does the report look like?

Each weekly evidence pack opens with a summary for the reporting period, then lists every vendor that ran on your payment pages with its written justification and each script it served (6.4.3), then shows all monitored security headers and what changed during the week, with before and after values (11.6.1). This example is from the Northwind demo.

![The cover of a weekly PCI DSS evidence pack: the report title, six summary tiles (17 vendors, 30 scripts, 13 approved, 2 requiring action, 2 blocked, 4 headers changed), the organization, payment domains and reporting period](https://docs.scriptmonitoring.com/screenshots/pci-report-cover-light.webp)
![The vendors and scripts section of the evidence pack: each vendor with its status, written justification and every script it served, with SHA-256 hashes and where it was seen](https://docs.scriptmonitoring.com/screenshots/pci-report-vendors-light.webp)
![The security headers section of the evidence pack: all 14 monitored headers with their value this week and a Changed, Unchanged or Not set status](https://docs.scriptmonitoring.com/screenshots/pci-report-headers-light.webp)

Click a page to open it full size, or [download the full example evidence pack (PDF, 12 pages)](https://docs.scriptmonitoring.com/examples/script-monitoring-pci-evidence-pack-example.pdf) to see every section, including the before and after values for each changed header. Every section is explained in the [PCI DSS reference](https://docs.scriptmonitoring.com/pci-dss/#what-is-in-the-evidence-pack).

## How do I keep the evidence current?

- Turn on the **PCI vendors need review** and **PCI evidence pack ready** notifications: see [Set up notifications](https://docs.scriptmonitoring.com/guides/notifications/).
- Review new vendors as they appear, so the Monday pack starts clean.
- When checkout routes change, update the selectors in Setup step 4 and check **Payment pages monitored**.

## Frequently asked questions

### How do I give the report to my assessor?

The report opens in the dashboard. Use **Print / Save as PDF** to save a copy to send. Viewing a report needs a dashboard login and membership of the team.

### Why can't I approve a vendor?

A vendor with open alerts cannot be approved until the alerts are resolved. You can still block it. Approval also needs a written justification.

## Related

- [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)
- [PCI DSS 6.4.3 & 11.6.1 (reference)](https://docs.scriptmonitoring.com/pci-dss/)
- [Approve or block a vendor](https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/)

---

# Set up notifications

> Edit or add a notification rule, choose its trigger, domains and destinations (email, webhook or S3), then send a test to check it arrives.

Source: https://docs.scriptmonitoring.com/guides/notifications/ · Plan: All plans · Updated 2026-10-13

To get alerted, open **Settings > Notifications**, edit a team rule (or add one), choose where it sends, and send a test. Which rules exist and which are on by default is on the [Notifications reference](https://docs.scriptmonitoring.com/notifications/).

## How do I set up a rule?

1. Open **Settings > Notifications**. Click a rule to edit it, or **New rule**.
2. Give it a **Name**.
3. **When**: choose the trigger and how often it sends (**Immediately**, **Daily digest** or **Weekly digest**, where the trigger allows).
4. **Where**: keep **All domains** on, or pick the domains the rule watches.
5. **Where to**: add destinations with **Email**, **Webhook** or **S3**.
6. Click **Save** (or **Create rule**), or **Save and send test**.

![The New rule sheet: pick what triggers the rule (for example Malicious script detected), how often it sends, which domains it watches and where it goes.](https://docs.scriptmonitoring.com/screenshots/rule-sheet-light.webp)

## How do I test a rule?

Click **Send test** on the rule's row, or **Save and send test** in the sheet. The result says **Test delivered**, **Partly delivered**, **Test failed** or **Test queued**. **Last delivery** is recorded for webhook and S3 destinations.

## Frequently asked questions

### Why can't I send a test for some rules?

Digests sent on a schedule, such as **New outbound connections to review** and **Recommended CSP header changed**, can't be tested from the sheet.

### The test says Test queued. Did it work?

The test was queued, but delivery was not confirmed within 30 seconds. Check your destination.

### How do I send alerts to Slack or Discord?

Add a webhook destination with **Format** set to **Slack** or **Discord**: see [Webhooks](https://docs.scriptmonitoring.com/webhooks/).

## Related

- [Notifications (reference)](https://docs.scriptmonitoring.com/notifications/)
- [Webhooks](https://docs.scriptmonitoring.com/webhooks/)

---

# Home

> Reference for the dashboard Home page: the critical alert banner, the seven tiles, high-risk vulnerabilities and top risks, and what each number links to.

Source: https://docs.scriptmonitoring.com/home/ · Plan: All plans · Updated 2026-10-13

**Home** is the first page in the dashboard's sidebar, under **Overview**. It answers "what needs me today?" for the selected team: a banner for critical alerts, seven tiles that each open the list behind them, the open high-risk vulnerabilities, and the top risks ranked by score. Pick a domain in the top bar to scope every section to that domain. Everyone in the team can see Home.

![Home for Payments platform: 1 critical alert on checkout.northwind.com, tiles for open alerts, vendors, scripts seen, payment pages, active blocks and quiet streams, and the top risks ranked by score.](https://docs.scriptmonitoring.com/screenshots/home-light.webp)

## What does the banner at the top say?

When there is at least one open critical alert or high-risk vulnerability, a banner counts them ("1 critical alert and 0 high-risk vulnerabilities open") and names up to two of the critical vendors with their domain and how long ago they fired. **Vulnerabilities** scrolls down to the vulnerability list, and **Review alerts** opens [Alerts](https://docs.scriptmonitoring.com/alerts/).

With nothing critical open, a note says "No critical alerts on" the team and domain scope, and how many lower-severity alerts are open.

When the team has used 80% or more of its plan's monthly page views, a usage note shows above the banner.

## What does each tile show?

![The Home tiles: 5 open alerts (1 critical), 3 needing action, 9 vendors, 13 scripts seen on 2 domains, 4 payment pages in PCI scope, 4 active blocks and no quiet streams.](https://docs.scriptmonitoring.com/screenshots/home-tiles-light.webp)

Every tile is a link. A red dot next to a label means it needs attention.

| Tile | What it counts | Opens |
| --- | --- | --- |
| Open alerts | Open alerts in the date range, minus decisions on **Not now**. The same number as the Alerts badge in the sidebar. The line below counts the critical ones. | [Alerts](https://docs.scriptmonitoring.com/alerts/) |
| Need action | Alert decisions that are critical or high risk. | [Alerts](https://docs.scriptmonitoring.com/alerts/) |
| Vendors | Vendors seen in the date range, and how many are not reviewed yet (not allowed, or with open alerts, and not blocked). Shows "100+" past 100. | [Vendors](https://docs.scriptmonitoring.com/vendors/) |
| Scripts seen | Distinct scripts seen in the date range. A script loaded on several domains counts once. | [Domains](https://docs.scriptmonitoring.com/domains/), or the domain's scripts when a domain is selected |
| Payment pages | Payment page selectors in PCI scope. | [PCI DSS](https://docs.scriptmonitoring.com/pci-dss/) |
| Active blocks | Block rules in force for the team. Blocks apply to every domain in the team. | [Blocks](https://docs.scriptmonitoring.com/blocks/) |
| Quiet streams | Domains with a monitoring stream that has gone quiet: no data for 6 or more full hours. "All reporting" when there are none. | [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/) |

## What is in High-risk vulnerabilities?

Open alerts for a script with a known vulnerability at high or critical severity, from an OSV advisory. A script flagged as malicious counts as critical. "These are the alerts we email you."

Each row shows:

- the severity, the package and version, and the advisory title,
- the script URL,
- the advisory ID, the page the script was loaded on, and when the alert was emailed (or "not emailed yet").

**Open** shows the details in a sheet, with **Open alert** to go to the alert and **Advisory on OSV** to read the advisory. **OSV** on the row opens the advisory directly. With nothing to show, the card says "No known vulnerabilities".

## How do I read Top risks?

![Top risks ranked by the priority score: n0rthwind.com 10.0 Critical, Google Tag Manager 8.0 High and Klaviyo 7.0 High, each needing review.](https://docs.scriptmonitoring.com/screenshots/home-top-risks-light.webp)

Top risks lists up to four open alert decisions, one per vendor, ranked by the priority score. Decisions that are critical or high come first. Each row shows:

- the score pill, such as "10.0 Critical" (see [How do I read the risk score?](https://docs.scriptmonitoring.com/alerts/#how-do-i-read-the-risk-score)),
- the vendor, its category, the domain and the script's path,
- up to two of the rules that fired, each with its rule score, and "+N" for the rest,
- a **Needs review** badge, since a vendor with open alerts has not been decided yet.

**Open** opens that decision in [Alerts](https://docs.scriptmonitoring.com/alerts/). **All** (with the count) opens the whole queue. With no open alerts, the card says "Nothing scored".

## What happens on the Free plan?

The Free plan stops at 1,000 page views a month. At the limit, Home's content is replaced by "You have reached the Free plan limit" and an **Upgrade** button, until the month ends or the team upgrades. Plans and prices are on the [pricing page](https://www.scriptmonitoring.com/pricing/).

## Frequently asked questions

### Why does a tile show "n/a"?

The number could not be read just now. The rest of Home still works, and the tile fills in on the next load.

### Why don't the payment pages and active blocks change with the date range?

They are current states, not events. **Payment pages**, **Active blocks** and **Quiet streams** show what is true now. Every other number follows the top bar's date range.

### How does Home pick the top risks?

It takes the open alert decisions that are not on **Not now**, ranks them by risk score, and shows up to four. Critical and high decisions come first; if there are none, it shows the highest of the rest.

### Why is Home empty on the Free plan?

The Free plan stops at 1,000 page views a month. From then until the month ends, Home shows "You have reached the Free plan limit" with an **Upgrade** button instead of data.

## Related

- [Your first week (guide)](https://docs.scriptmonitoring.com/guides/first-week/)
- [Triage alerts (guide)](https://docs.scriptmonitoring.com/guides/triage-alerts/)
- [Alerts](https://docs.scriptmonitoring.com/alerts/)

---

# Domains

> Reference for Security > Domains: the columns and reporting statuses, the Add domain sheet, Script tag or Agentic crawler, and who can add or remove domains.

Source: https://docs.scriptmonitoring.com/domains/ · Plan: All plans · Updated 2026-10-13

**Security > Domains** lists every domain the team monitors, with how each one is monitored, whether it is reporting, and its scripts, open alerts and page views. Super admins and Admins of the team add domains with **Add domain** and remove them from a row's menu. Everyone in the team can see the list. To install the tag on a new domain, [follow the install guide →](https://docs.scriptmonitoring.com/install/).

![Domains: pay.northwind.com and checkout.northwind.com, both payment pages, Receiving, with their scripts, open alerts and page views in the last 30 days.](https://docs.scriptmonitoring.com/screenshots/domains-light.webp)

## What does the list show?

The heading counts the team's domains. Above the list:

- a search field, "Search N domains", that matches the domain name,
- **Payment domains only**, with a count, to show only domains that have payment page selectors.

The **Monitored domains** card shows the number of domains and the distinct scripts seen across them in the top bar's date range. A script on several domains counts once.

| Column | What it shows |
| --- | --- |
| Domain | The domain, a **Payment page** badge if it has payment page selectors, the date it was added, and how it is monitored: **Script tag** or **Agentic crawler**. |
| Reporting | Whether the domain is sending data (see below). |
| Scripts | Distinct scripts seen on the domain in the date range. |
| Open alerts | Open alerts for the domain in the date range. Click the number to open them in [Alerts](https://docs.scriptmonitoring.com/alerts/). |
| Page views 30d | Page views from the domain in the last 30 days. |

A dash means the number could not be read. **Retry statistics** under the list reads them again.

## What do the reporting statuses mean?

| Status | Meaning |
| --- | --- |
| Receiving | The tag's streams have data. |
| Not receiving | A stream has had no data for 6 or more full hours. Click it to open the domain's [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/). |
| Not receiving, "No reading from the script tag yet" | No report has arrived from the tag. Check the [install](https://docs.scriptmonitoring.com/verify/). |
| Not receiving, "Agentic crawler only, no live stream" | The domain is crawled on a schedule, so it has no live stream. |
| Suspended | Monitoring is suspended for the domain. |
| Unavailable | The status could not be read just now. |

## What is in a row's actions?

- **Focus** scopes the dashboard to this domain, the same as picking it in the top bar.
- **Settings** (Agentic crawler domains only) opens the crawler settings.
- The **⋯** menu has **Crawl now**, which queues a crawl right away instead of waiting for the next scheduled one (one manual crawl a minute per domain), and **Remove domain**.

**Remove domain** asks you to confirm. It stops all monitoring for the domain and cannot be undone.

## What is in the Add domain sheet?

![The Add domain sheet: enter the domain and choose how to monitor it, with the Script tag (every page reports from real visitors) or the Agentic crawler.](https://docs.scriptmonitoring.com/screenshots/add-domain-sheet-light.webp)

- **Domain**: paste a URL or type a hostname, like `beverage.ltd`. The sheet checks the domain as you type.
- **How should we monitor this domain?**: **Script tag** (every page reports from real visitors' browsers) or **Agentic crawler** (scheduled crawls, nothing to install). The Agentic crawler is included in Pro and Enterprise.
- **Advanced**: **Wildcard domain** covers every subdomain. It is not available for a subdomain or a domain on the Public Suffix List.

**Next** lets you name subdomains you want to refer to in the dashboard, then **Add domain** adds it. The last step links to **Install the script tag** for a Script tag domain, or to **Crawler settings** for an Agentic crawler domain.

**Bulk import** adds several domains from a CSV file (up to 5 MB) with the columns `domain`, `type`, `subdomains` and `wildcard`:

```csv
domain,type,subdomains,wildcard
example.com,script-mode,www:shop:a.b.c,true
www.beverage.ltd,scan-mode,api,false
```

`domain` and `type` are required. `type` is `script-mode`, or `scan-mode` for the Agentic crawler (Pro and Enterprise). Subdomains are separated by colons, and `wildcard` is `true` or `false`. You can also register domains from your backend with the [REST API](https://docs.scriptmonitoring.com/api/domains/create/).

## Who can add and remove domains?

Super admins, and Admins of the team. Viewers see the list without **Add domain** or **Remove domain**.

## Frequently asked questions

### What is the difference between Script tag and Agentic crawler?

With **Script tag**, every page reports from real visitors' browsers as scripts run. With **Agentic crawler**, Script Monitoring crawls your site on a schedule and records the scripts it loads. Nothing to install, but it can miss scripts that only target real visitors. The Agentic crawler is included in Pro and Enterprise.

### Why does a domain say "Not receiving"?

For a Script tag domain, either no report has arrived from the tag yet, or a stream has had no data for 6 or more full hours. Click the badge to open the domain's [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/). An Agentic crawler domain always reads "Not receiving" because it has no live stream.

### What does a wildcard domain cover?

Every subdomain of the domain. You can't wildcard a subdomain, or a domain on the Public Suffix List.

### Can I undo removing a domain?

No. Removing a domain stops all monitoring for it and cannot be undone. Add it again to resume monitoring.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/)

---

# Alerts

> Reference for Security > Alerts: how decisions are grouped, the 1 to 10 risk score and its bands, what Allow, Block and Not now do, and who can act.

Source: https://docs.scriptmonitoring.com/alerts/ · Plan: All plans · Updated 2026-10-13

**Security > Alerts** is the queue of open alerts in the top bar's date range, grouped into one decision per vendor and ranked by a risk score from 1 to 10. Each decision has three actions: **Allow** approves the vendor and resolves its alerts, **Block** stops the flagged scripts on every domain in your team, and **Not now** hides the decision for 7 days. To work through the queue step by step, [follow the guide →](https://docs.scriptmonitoring.com/guides/triage-alerts/).

![Alerts: 5 open alerts grouped into 5 vendor decisions, each with a severity, a score pill, what happened, the script URL, and Allow, Block and Not now actions.](https://docs.scriptmonitoring.com/screenshots/alerts-light.webp)

## What does a row show?

One row is one decision: the vendor (or the script host when it is not a known vendor), its severity, its score pill, and what happened. A decision with one alert shows the plain-language phrase and the script URL; with several it shows how many and on which hosts. Opening a row shows every open alert for the vendor: what happened, the script URL, why the rule fired, the rule name and score, the domain and when.

The filter chips are **All**, **Needs action** (critical and high decisions), **Critical**, **High**, **Medium** and **Low**. **Export** downloads the current queue as a CSV.

## How do I read the risk score?

Each row has a score pill, such as "9.9 Critical". Every detection rule carries a fixed risk score from 1 to 10, set in the rule catalog and the same for every customer. An alert scores the highest of its rules that are still open, and a decision shows the highest score among its vendor's open alerts. Click a pill (**Why this score**) to see the rules behind it.

| Band | Score | Respond |
| --- | --- | --- |
| Critical | 9.0 to 10 | Same business day |
| High | 7.0 to 8.9 | Within 24 hours |
| Medium | 4.0 to 6.9 | Within 7 days |
| Low | Under 4.0 | No action needed |

A known vulnerability that carries its own advisory severity keeps that severity on its alert.

## What does each action do?

### Allow

**Allow** approves the vendor for the whole decision, not only the alerts the current filter shows:

- it resolves every open alert in the decision,
- it records an explicit allow for each behavior the vendor was seen using,
- and if the vendor was blocked, it lifts that block.

If a filter hides some of the vendor's alerts, a sheet asks you to confirm first. The toast has **Undo**: undoing makes the vendor need review again, and the resolved alerts stay resolved.

### Block

**Block** opens a sheet that lists the flagged scripts and the domains they load on. **Block now** stops those scripts on every domain in the team within 60 seconds and resolves the alerts. The vendor's other scripts keep loading. Blocked scripts are listed under [Blocks](https://docs.scriptmonitoring.com/blocks/), which also compares blocking here with blocking a whole vendor.

### Not now

**Not now** snoozes the decision for 7 days. It moves to **Suppressed** at the bottom of the page ("Scored and cleared, never hidden") and returns when the 7 days are up, or earlier if a new alert fires for that vendor. **Bring back** returns it to the queue immediately.

## What do the alert descriptions mean?

Each alert starts with a plain-language phrase for the rule that fired. Some common ones:

| Phrase | What the rule saw |
| --- | --- |
| Checkout fields read by a script from a new domain | A script on a newly seen domain hooks into payment fields. |
| Payment skimmer found on the page | Known card-skimming code. |
| Script captures keystrokes or form fields | Keylogger-like behavior. |
| Matched Script Monitoring Threat Intelligence | The script is on the Script Monitoring Threat Intelligence list. |
| Page connected to a flagged destination | The page sent data to a destination on the threat list. |
| Flagged Tag Manager container loaded | A tag manager container on the threat list was loaded. |
| Script served from an IP address | The script URL uses a bare IP address instead of a domain. |
| Vulnerable library version loaded | A library version with a known vulnerability. |

## Who can act on alerts?

Super admins and Admins can allow, block and snooze. Viewers see the queue with a note that only Super admins and Admins can allow and block. **Export** downloads the current queue as a CSV for anyone.

## Frequently asked questions

### Why are my alerts grouped?

A decision is one per vendor. All open alerts for scripts from the same vendor are grouped into one row, so one Allow or Block covers them. Scripts from a host that is not a known vendor are grouped by host.

### Where does the score come from?

Every detection rule has a fixed risk score from 1 to 10, the same for every customer. An alert scores the highest of its open rules, and a decision shows its highest alert score.

### What happens to a decision I put on Not now?

It moves to **Suppressed** for 7 days and comes back after that, or earlier if a new alert fires for that vendor.

## Related

- [Triage alerts (guide)](https://docs.scriptmonitoring.com/guides/triage-alerts/)
- [Vendors](https://docs.scriptmonitoring.com/vendors/)
- [Blocks](https://docs.scriptmonitoring.com/blocks/)

---

# Blocks

> Stop a script at the Script Monitoring edge on every domain in your team, check the rule is enforced, and respond to a malicious script step by step.

Source: https://docs.scriptmonitoring.com/blocks/ · Plan: All plans · Updated 2026-10-13

**Security > Blocks** holds the rules that stop scripts from loading. A rule matches a script URL, a host or a domain, applies to every domain in your team, and reaches the Script Monitoring edge in under 60 seconds, so no deploy is needed on your side. Most blocks start from an alert; this page covers the rules themselves and blocking a script that has no alert.

![Blocks: active block rules for a URL, a hostname and a domain, who added each one and why, and the approved-tags rule.](https://docs.scriptmonitoring.com/screenshots/blocks-light.webp)

## How do I block a script?

1. Open **Security > Blocks** and click **Block a script**.
2. Under **Script URL or pattern**, enter the script, host or domain (see the patterns below).
3. Add a **Reason** if you like. It is shown under the rule.
4. Click **Add block rule**. The toast says it is live at the edge in under 60 seconds.

![The Block a script sheet: the script URL or pattern to block on every Payments platform domain, and an optional reason shown under the rule.](https://docs.scriptmonitoring.com/screenshots/block-script-sheet-light.webp)

## Which patterns can I block?

| You enter | What it blocks |
| --- | --- |
| `https://cdn.vendor.com/lib/app.js` | That exact script URL. |
| `https://cdn.vendor.com/*` or `cdn.vendor.com/*` | Everything served from that host. |
| `vendor.com` | That domain and its subdomains. |
| `shop.vendor.com` | That host. |

Only a whole host can be matched with `*`: paths cannot be wildcarded.

## How do I know a block is enforced?

Under **Active block rules**, each rule shows its pattern, reason, who added it and its status:

- **Blocking**: enforced at the edge. Hover to see when it last blocked a request.
- **No matches**: in force at the edge, but no script matched it in the date range yet.

## How do I lift a block?

Click **Allow** on the rule's row. The toast has **Undo**. Global rules added by Script Monitoring cannot be removed.

## Should I block from Alerts, Vendors or Blocks?

| Where | What it stops |
| --- | --- |
| **Block** on an [alert decision](https://docs.scriptmonitoring.com/alerts/) | Only the scripts flagged in that decision. The vendor's other scripts keep loading. |
| **Block** on a [vendor](https://docs.scriptmonitoring.com/vendors/) | Every resource the vendor serves: scripts, images, fonts, frames, stylesheets and any other request. |
| **Block a script** on this page | Exactly the URL, host or domain you enter. |

All three apply to every domain in the team, and all three show up here.

## What if the script is malicious?

Block it first, then investigate: follow [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/).

## Frequently asked questions

### How fast does a block take effect?

Block rules reach the edge in under 60 seconds and apply to every domain in the team. They survive redeploys of your own site.

### Can I block a script by its hash?

No. Blocking by script hash is no longer supported. Block the script URL, its host or its domain.

### Who can add or lift blocks?

Super admins and Admins. Viewers can see the rules but cannot change them.

## Related

- [Alerts](https://docs.scriptmonitoring.com/alerts/)
- [Vendors](https://docs.scriptmonitoring.com/vendors/)
- [Respond to a malicious script](https://docs.scriptmonitoring.com/guides/malicious-script/)

---

# Approved tags

> Reference for Security > Approved tags: approve the Google Tag Manager containers your site may load, and every other container is blocked before it runs.

Source: https://docs.scriptmonitoring.com/approved-tags/ · Plan: All plans · Updated 2026-10-13

**Security > Approved tags** is an allow list for Google Tag Manager containers. Once you approve one container ID, every other Google Tag Manager container is blocked before it runs, on every domain in the team, so a container added outside your change process can't ship code to your visitors. Each container has one decision: **Allow** puts it on the list, **Block** takes it off. Super admins and Admins of the team can change the list.

![Approved tags: the Google Tag Manager containers allowed to load. GTM-K93PLQ7 and GTM-5BQ7XR2 are approved; GTM-N7WQ2PX was injected on pay.northwind.com and is blocked.](https://docs.scriptmonitoring.com/screenshots/approved-tags-light.webp)

## Why isn't Approved tags in my sidebar?

The page is turned on per team, because approving a container changes what your site can load. When it is on, **Approved tags** shows under **Security**, after **Blocks**. To turn it on for your team, [talk to an expert](https://www.scriptmonitoring.com/contact/).

## What does the Tag allow list show?

The **Tag allow list** card counts how many containers are approved ("2 of 3 approved"). It lists every approved container, then every Google Tag Manager container seen on your domains in the last 24 hours that is not approved.

| Column | What it shows |
| --- | --- |
| Provider | Google Tag Manager, and the container ID. |
| Domains | Where the container loaded in the last 24 hours, or **All domains** when it loaded on every domain. "Not seen in 24 hours" when it did not load. |
| Status | **Approved**, **Blocked** or **Needs review** (see below). |
| Decision | **Allow** or **Block**. |

With no containers yet, the card says "No tags yet".

## What do the statuses mean?

| Status | Meaning |
| --- | --- |
| Approved | On the allow list. It can load. |
| Blocked | Not on the list while at least one container is approved, so it is blocked. |
| Needs review | Seen on your domains, but nothing is approved yet, so nothing is blocked. |

While nothing is approved, **Block** is disabled: approve at least one container to start blocking the rest.

## What do Allow and Block do?

- **Allow** adds the container to the list. The confirmation reads "Only approved container IDs can load."
- **Block** on an approved container removes it from the list. It stops loading within a few minutes. If it was the last approved container, the restriction is lifted and every Google Tag Manager container loads again.

Every change saves straight away and applies to all of the team's domains. The toast has **Undo**.

## What is the banner above the list?

When an unapproved container loaded in the last 24 hours, a banner says how many "are injecting tags without approval" and names the first one and the domain it loaded on. **Approve container** approves it.

## How do I approve a container that hasn't loaded yet?

Click **Approve a tag** at the top of the page. In the sheet, enter the **Google Tag Manager container ID**, such as `GTM-ABC1234`, and click **Approve tag**. It applies to all of the team's domains.

## Who can change the list?

Super admins, and Admins of the team. Viewers can see the list, but their changes are refused.

## Frequently asked questions

### Why don't I see Approved tags in the sidebar?

The page is turned on per team. If your team doesn't have it, [talk to an expert](https://www.scriptmonitoring.com/contact/).

### What happens when I approve the first container?

From then on, only approved containers load. Every other Google Tag Manager container is blocked on all of the team's domains.

### What happens if I remove the last approved container?

The restriction is lifted, so every Google Tag Manager container loads again.

### Which tag providers are supported?

Google Tag Manager. Container IDs look like `GTM-ABC1234`.

## Related

- [Blocks](https://docs.scriptmonitoring.com/blocks/)
- [Vendors](https://docs.scriptmonitoring.com/vendors/)

---

# Vendors

> Reference for Security > Vendors: vendor statuses, what the details sheet shows, what Allow and Block do, the pinned rows and the Pro features.

Source: https://docs.scriptmonitoring.com/vendors/ · Plan: All plans · Updated 2026-10-13

**Security > Vendors** lists every third party observed on your pages in the top bar's date range, one row per vendor, with one decision each: **Allow** approves it and records what it is allowed to do, **Block** stops every resource it serves on all of the team's domains. Alerts and the PCI DSS evidence use the same decision. To review vendors step by step, [follow the guide →](https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/).

![Vendors: every third party seen on Payments platform in the last 7 days with its category, review status, highest score and what it does on the page, plus Allow and Block.](https://docs.scriptmonitoring.com/screenshots/vendors-light.webp)

## What do the statuses mean?

| Status | Meaning |
| --- | --- |
| Approved | Someone allowed the vendor and it has no open alerts. |
| Needs review | Nobody has decided yet, or it raised an alert since. |
| Blocked | Every resource it serves is stopped on all of the team's domains. |

## What does a vendor's details sheet show?

- **Why it scored**: the rule behind its risk score, or "Not scored" if none of its scripts raised an alert.
- **Load chain**: whether your page loads it directly or another vendor does (Pro and Enterprise).
- **PCI DSS 4.0.1**: whether it runs on a payment page, and whether it has a recorded justification.
- **Seen pages**: the pages it runs on, each marked **Payment page** or **Not a payment page**.
- **What it does on the page** and **Permissions** (per-vendor permissions are Pro and Enterprise).
- The **Sub-scripts** and **Alert rules** tabs.

## What does Allow do?

**Allow** approves the vendor: it lifts the vendor's block, if it had one, and records an explicit allow for everything the vendor was seen doing. The vendor turns **Approved** once it has no open alerts. Allowing from **Security > Alerts** also resolves the vendor's open alerts.

## What does Block do?

**Block** stops every resource the vendor serves (not only scripts, but images, fonts, frames, stylesheets and any other request) on every domain in the team, after you give a reason. How this compares with blocking from an alert: [Should I block from Alerts, Vendors or Blocks?](https://docs.scriptmonitoring.com/blocks/#should-i-block-from-alerts-vendors-or-blocks).

## What are the two pinned rows?

- **Default configuration** applies to every script unless a vendor's configuration overrides it. Its badge says **Allows by default**, **Blocks by default** or **Custom default**.
- **Inline code** covers inline sources and `data:` URLs. It has no vendor to block.

## What else is in a row's menu?

**Open vendor details**, and **Reset reviewed permissions**, which sends the vendor back to needing review.

## Frequently asked questions

### What does "Needs review" mean?

Nobody has decided on the vendor yet, or it raised an alert since it was approved. Alerts and Vendors share this status.

### Why can't I see the load chain or per-vendor permissions?

The vendor load chain and per-vendor permissions are included in Pro and Enterprise. Allowing and blocking a vendor work on every plan.

### Can I undo an Allow or a Block?

Yes. Allow shows an **Undo** in its toast, and allowing a blocked vendor lifts its block.

## Related

- [Approve or block a vendor (guide)](https://docs.scriptmonitoring.com/guides/approve-or-block-a-vendor/)
- [Alerts](https://docs.scriptmonitoring.com/alerts/)
- [Blocks](https://docs.scriptmonitoring.com/blocks/)

---

# CSP violations

> Reference for Security > CSP violations: the weekly violation table and its columns, the directive filters, monthly report limits and the CSV export.

Source: https://docs.scriptmonitoring.com/csp-violations/ · Plan: All plans · Updated 2026-10-13

**Security > CSP violations** lists the Content Security Policy violations that browsers report for your domains, grouped by week, with the offending URL, the page it happened on, whether it was reported or blocked, and how often. Reports start once your server sends the reporting headers: [set up CSP reporting →](https://docs.scriptmonitoring.com/csp-reporting/). CSP violations are on every plan, and everyone in the team can see them.

![CSP violations: reports from your domains grouped by week, with the offending URL, domain, document, whether it was reported or blocked, the count and the directive.](https://docs.scriptmonitoring.com/screenshots/csp-violations-light.webp)

## What does the page show?

A bar at the top says where reports go: "Reporting to csp.scriptmt.com on" the number of domains reporting, or the domain picked in the top bar. **Set up another domain** opens the CSP setup sheet.

If no domain has finished setup (or the selected domain has not), the page says "CSP reporting isn't set up yet" with **Set up CSP reporting** (or **Set up this domain**) instead of the table.

The window is the top bar's date range, extended back to the start of its first week. History goes back 30 days on Free and Pro, and 90 days on Enterprise.

## What does each column mean?

The **Violations by week** card groups rows under "Week of" headers, newest week first. Its header shows how many reports the team received this month, against the plan's limit.

| Column | What it shows |
| --- | --- |
| Offending URL | The URL the policy objected to, and its domain. Inline code and `eval` show as `inline` and `eval`. |
| Domain | Your domain that reported it. |
| Document URI | The page where it happened, and the script that caused it, or **Standalone script** when the page loaded it directly. |
| Status | **Reported** (report-only policy) or **Blocked** (enforced policy). |
| Total violations | How many times it was reported that week. |
| Last violation | When it was last reported, and the directive it broke. |
| Block type | What kind of resource it was, such as External, Inline or Eval. |

Sort by **Offending URL**, **Domain**, **Total violations** or **Last violation** by clicking the column header. By default, the most recent violation comes first within each week.

## How do I filter violations?

- **Search offending URLs** matches part of the offending URL.
- The directive chips filter by directive: **All directives**, `script-src`, `connect-src`, `img-src`, `style-src`, `frame-src` and `font-src`.
- The domain picker in the top bar shows one domain.

## How many reports does my plan show?

| Plan | Reports shown per month |
| --- | --- |
| Free | 50,000 |
| Pro | 1,000,000 |
| Enterprise | Set by your contract |

Past the limit, a banner says "You reached this month's limit" with the number. Reports beyond it are still collected but are not shown until the next month. **Upgrade** opens the plan options.

## How do I export violations?

**Export CSV** opens a sheet to export the raw reports behind the table:

- Pick a date range of up to 91 days, within the last 3 months (raw reports are kept for 3 months).
- The domain and URL search apply. The directive chip does not apply yet, so the file covers every directive.
- **Export** prepares the file in the background and emails a download link to you.

Over the monthly limit, exports are limited to the plan's monthly allowance. Anyone in the team can export.

## Frequently asked questions

### Why does the page say CSP reporting isn't set up?

No domain in the team (or the domain picked in the top bar) has finished CSP reporting setup. Click **Set up CSP reporting** and follow [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/).

### What is the difference between Reported and Blocked?

**Reported** comes from a report-only policy: the browser would have blocked the resource but let it load. **Blocked** comes from an enforced policy: the browser stopped it.

### What happens when I pass the monthly limit?

Reports beyond the limit are still collected, just not shown on the page until next month. A banner says so, with **Upgrade** for a higher limit.

### Does the directive filter apply to exports?

Not yet. An export covers every directive. The domain and the URL search do apply.

## Related

- [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/)
- [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/)

---

# PCI DSS 6.4.3 & 11.6.1

> Reference for Compliance > PCI DSS 6.4.3 & 11.6.1: the Vendors, Headers, Reports and Payment pages monitored tabs, their statuses and the evidence pack.

Source: https://docs.scriptmonitoring.com/pci-dss/ · Plan: All plans · Updated 2026-10-13

**Compliance > PCI DSS 6.4.3 & 11.6.1** is your evidence for the two client-side requirements, generated from what Script Monitoring observed on your payment pages. The **Vendors** tab covers 6.4.3 (an inventory of payment-page scripts with a justification for each vendor), the **Headers** tab covers 11.6.1 (changes to the security headers on those pages), **Reports** packages both into a weekly evidence pack, and **Payment pages monitored** shows the scope. To produce the evidence step by step, [follow the guide →](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/). For what the requirements ask, see [6.4.3](https://www.scriptmonitoring.com/pci-dss-6-4-3/) and [11.6.1](https://www.scriptmonitoring.com/pci-dss-11-6-1/).

The page follows the top bar's domain and date range. A PCI view covers at most 10 days at a time.

## What does the Vendors tab show? (6.4.3)

One row per vendor seen on your payment pages: **Vendor**, **Justification**, **Category**, **Last Seen** and **Status**. The tab label counts the vendors that need review.

![PCI DSS, Vendors (6.4.3): every vendor on a payment page with its justification, category, last seen date and status: Approved or Needs review.](https://docs.scriptmonitoring.com/screenshots/pci-vendors-light.webp)

| Status | Meaning |
| --- | --- |
| Approved | Justified and approved. |
| Needs review | Not yet approved, blocked or ignored. |
| Blocked | Stopped from loading. |
| Ignored | Hidden from PCI review and reports, with a justification. |

- A vendor with open alerts cannot be approved until the alerts are resolved. It can still be blocked.
- A script can carry its own justification that overrides the vendor's.
- On Pro and Enterprise, **AI auto-approval for PCI DSS** drafts a justification for each vendor and approves the ones it can justify.

## What does the Headers tab show? (11.6.1)

The latest week inside your date range.

![PCI DSS, Headers (11.6.1): a change calendar of security headers on payment pages over the week and the list of header changes.](https://docs.scriptmonitoring.com/screenshots/pci-headers-light.webp)

- **Change calendar**: one row per header, one cell per day. Cells say **Value changed** (amber), **Stable**, **Not sent** or **No reading yet**.
- **Values over time**: how each header's values were shared across pages.
- **Security header changes**: each change by date. Nonces are left out, because they change on every response.

## What does the Reports tab show?

**Weekly evidence packs** on file, newest first: the **Period**, the **Contents** (vendors, how many need action, header changes) and the **Status**.

![PCI DSS, Reports: weekly evidence packs with the vendors needing action and header changes each week, all Ready to download.](https://docs.scriptmonitoring.com/screenshots/pci-reports-light.webp)

| Status | Meaning |
| --- | --- |
| Ready | Open it with **PDF**. |
| Generating | Being built, usually a few minutes. |
| Shortened | The inventory lists a limited number of scripts per vendor. |
| Failed | The report could not be built. Generate it again. |

### What is in the evidence pack?

A cover page, the week's stats, the vendor and script inventory with each justification (vendors that need action first), and the security header changes. It opens in the dashboard, where **Print / Save as PDF** saves a copy.

[Download an example evidence pack (PDF, 12 pages)](https://docs.scriptmonitoring.com/examples/script-monitoring-pci-evidence-pack-example.pdf) from the Northwind demo.

## What does the Payment pages monitored tab show?

Every page Script Monitoring treats as a payment page and the selector that put it there: the scope both 6.4.3 and 11.6.1 are measured against.

![PCI DSS, Payment pages monitored: the pages in scope, the selector that matched each one, scripts and script loads per page, and pages seen on a payment domain but not in scope.](https://docs.scriptmonitoring.com/screenshots/pci-pages-light.webp)

- Tiles: **Pages in scope**, **Selectors**, **Script loads** and **Seen but not in scope**.
- **Pages in scope**: each page, the selector that matched it, its scripts and script loads, and when it was last seen.
- **Seen on a payment domain, not in scope**: pages no selector matches, each with **Add to scope**.
- **Edit scope in Setup** opens [Payment pages](https://docs.scriptmonitoring.com/payment-pages/) in Setup step 4.

## Frequently asked questions

### Which plan includes the PCI DSS evidence?

Every plan, Free included, has the PCI DSS dashboard and the weekly evidence pack. AI auto-approval of vendors is on Pro and Enterprise.

### How often is a report created?

Script Monitoring creates a weekly evidence pack every Monday at 12:00 UTC. You can also generate one at any time with **Generate now**. Packs are kept at least 18 months.

### How do I give the report to my assessor?

The report opens in the dashboard. Use **Print / Save as PDF** to save a copy to send. Viewing a report needs a dashboard login and membership of the team.

## Related

- [Prepare PCI DSS evidence (guide)](https://docs.scriptmonitoring.com/guides/pci-dss-evidence/)
- [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)

---

# Setup

> Reference for Developers > Setup: the five steps (Use case, Site type, Install, Scope, Verify), what each asks and why, and who can change them.

Source: https://docs.scriptmonitoring.com/setup/ · Plan: All plans · Updated 2026-10-13

**Developers > Setup** is where a team gets the tag and tells Script Monitoring what to watch, in five steps: **Use case**, **Site type**, **Install**, **Scope** and **Verify**. It is set once per team, because the script is issued per team and every domain in it uses the same tag. New accounts land on step 1 right after sign-up. Super admins and Admins of the team can change every step; Viewers can read it all.

![The Setup page for the Payments platform team: a five-step stepper (Use case, Site type, Install, Scope, Verify) with step 1 asking what you are monitoring for.](https://docs.scriptmonitoring.com/screenshots/setup-overview-light.webp)

## How does Setup work?

The stepper at the top shows the five steps: **Use case** (what you are monitoring for), **Site type** (how your pages load), **Install** (add the tag), **Scope** (which pages report) and **Verify** (confirm it is live). Click any step to open it, or use **Back** and **Continue** at the bottom of the card. On step 5, **Done, go to Diagnostics** takes you to [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/).

Each answer is saved the moment you pick it, so there is no Save button for the steps. A step shows a check once it is done:

| Step | Done when |
| --- | --- |
| 1. Use case | A use case is chosen. |
| 2. Site type | A site type is chosen. |
| 3. Install | A domain in the team has sent a script report. |
| 4. Scope | A use case is chosen and Scope shows no blocking problem, such as **No payment page defined**. |
| 5. Verify | Steps 3 and 4 are both done. |

Each step has its own URL, so you can share a link to it. When you open Setup from **Edit scope in Setup** on the PCI DSS **Payment pages** tab, a **Back to PCI** link takes you back.

## When does Setup appear?

A new account opens Setup step 1 straight after sign-up, on the team that was created for it. A login that has just created the workspace opens it too. After that, logins land on [Home](https://docs.scriptmonitoring.com/home/), and you reach Setup from **Developers > Setup** in the sidebar.

## Who can change Setup?

| Role | What they can do |
| --- | --- |
| Super admin | Everything: answer every step, edit payment page selectors, change the Advanced settings. |
| Admin of the team | The same as a Super admin, for that team. |
| Viewer | Read every step, copy the snippet, test a URL and see Verify. The choices are disabled, with "You do not have permission to manage this team" on hover. |

## What does step 1, Use case, ask?

**What are you monitoring for?** It is asked first because it decides how much of your site reports back. You can change it later without reinstalling.

![Setup step 1, Use case: choose Client-side security, PCI DSS 6.4.3 & 11.6.1, or Both.](https://docs.scriptmonitoring.com/screenshots/setup-step-1-light.webp)

| Use case | What reports |
| --- | --- |
| **Client-side security** | Every page. Every third-party script is inventoried and alerted on. No payment pages to set. |
| **PCI DSS 6.4.3 & 11.6.1** | Scoped to your payment pages. The tag still loads on every page, and you can narrow reporting to the payment pages in step 4. Vendors, Alerts and Blocks then show only what runs on a payment page. |
| **Both** | Every page, and your payment pages are also tracked as a named PCI scope for 6.4.3 and 11.6.1. |

Pick **Both** if an assessor may ask for PCI DSS evidence and you also want cover on the rest of the site. Switching away from **PCI DSS 6.4.3 & 11.6.1** turns off **Only payment pages report**, so every page reports again.

If your workspace is still named after your email address, step 1 also asks for a **Company name**. **Save** renames the organization and its first team after your company.

## What does step 2, Site type, ask?

**Is this a single-page app?** It applies to every domain in the team and changes how the tag detects a page at all, so answer it before you install.

![Setup step 2, Site type: Multi-page site is selected; Single-page app is the alternative.](https://docs.scriptmonitoring.com/screenshots/setup-step-2-light.webp)

- **Multi-page site**: every navigation loads a new document. Server-rendered sites, classic checkout flows and most commerce platforms.
- **Single-page app**: routes change without a reload (React, Vue, Svelte, Angular, Next in client mode). The tag watches route changes instead of page loads.

For a single-page app, Setup also asks **How does your router write URLs?**: **Path routing** (`/checkout/payment`) or **Fragment routing** (`/#/checkout/payment`). With fragment routing, payment page selectors must include the fragment, such as `/#/checkout`.

## What does step 3, Install, show?

The card is titled **Install with** the method you pick, and its header shows your team's **Script URL**, `https://<teamID>.cdn.scriptmt.com/sm.js`. Every method installs the same tag, filled in with your team ID (a 14-digit number starting with 1, such as `14827391650423`), with a **Copy** button.

![The install step showing the script tag for the Payments platform team and the install method tabs: HTML, GTM, AI, NextJS, Vite and CLI.](https://docs.scriptmonitoring.com/screenshots/setup-install-snippet-light.webp)

The method tiles, and where each one is explained step by step:

- **HTML**: paste the tag at the top of the `<head>`. See [Install with HTML](https://docs.scriptmonitoring.com/install/html/).
- **GTM**: a Custom HTML tag in Google Tag Manager, for testing only. See [Google Tag Manager](https://docs.scriptmonitoring.com/install/google-tag-manager/).
- **AI**: a prompt for your AI coding assistant. See [AI assistant](https://docs.scriptmonitoring.com/install/ai-assistant/).
- **NextJS**: the Next.js component. See [Next.js](https://docs.scriptmonitoring.com/install/nextjs/).
- **Vite**: the Vite plugin. See [Vite](https://docs.scriptmonitoring.com/install/vite/).
- **CLI**: inject the tag after your build. See [CLI](https://docs.scriptmonitoring.com/install/cli/).

If you marked the site as a single-page app in step 2, a note above the tiles recommends a method by who owns the HTML shell, and GTM shows a warning that it is a poor fit for production.

Below the snippet, **CSP reporting** explains that Content Security Policy reports come from your server's headers, not the tag. **Set up CSP reporting** opens the setup sheet on CSP violations for the domain picked in the top bar. See [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/).

### What is under Advanced?

**Advanced**, at the bottom of step 3, holds the team's install settings:

- **Release channel**: which web script release the tag serves, **Latest** (the default) or **Stable**.
- **Page URL query strings**: removes query strings from page URLs before they are stored. Turn it on if your URLs carry secrets such as password reset tokens or magic links. Script URLs and URLs already stored are not changed.
- **Page monitoring scope**: URL patterns for which pages the script monitors. With no patterns, every page is monitored. Shown only for teams that have it.
- **Custom request headers**: headers attached to the script's requests so you can identify and filter them. **Add header**, then **Save request headers**.

Only Super admins and Admins of the team can change these.

## What does step 4, Scope, show?

Scope depends on the use case. With **Client-side security**, the card is **Whole site**: every domain in the team is listed and there is nothing to configure. With **PCI DSS 6.4.3 & 11.6.1** it is **Payment pages only**, and with **Both** it is **Whole site, plus a PCI scope**.

![The Scope step on the Setup page, with payment page selectors per domain, a field to test a real URL, Import CSV and Report options.](https://docs.scriptmonitoring.com/screenshots/setup-scope-light.webp)

For PCI DSS and Both, Scope has:

- **Payment page selectors**: one list that decides both what counts as a payment page for the tag and what a PCI DSS report counts as one. Type a path such as `/checkout/:step` and click **Add selector**. `*` matches anything in a segment, `:name` matches one segment, and query strings are stripped before matching. Teams that keep selectors per domain pick the domain first, and can **Import CSV**.
- **Test a real URL**: paste a checkout URL to see **Matches** (and which selector matched it) or **No match** before you rely on a selector.
- **Report options**: a side sheet with how the team's PCI DSS reports are generated.
- **Only payment pages report** (PCI DSS only): when on, pages that no selector matches send nothing, though the tag still loads on them. It becomes available once a selector has matched a real page in the last 7 days, and turning it on asks you to confirm. If it is not enabled for your team yet, Scope says so and offers **Contact support**.

![Payment page selectors for checkout.northwind.com: /checkout and /checkout/:step, where :name matches one path segment and * matches anything.](https://docs.scriptmonitoring.com/screenshots/setup-payment-pages-light.webp)

Scope also warns when the setup can be silently wrong: **No payment page defined** (PCI DSS or Both with no selector, which keeps step 4 from being done), **No domain here is marked as taking payment**, a routing mismatch between step 2 and a selector, or **A selector contains a query string**. For how to write selectors and fix each warning, see [Payment pages](https://docs.scriptmonitoring.com/payment-pages/).

## What does step 5, Verify, check?

The **Activation** card reads only what has really arrived: tag requests delivered this month and script reports in the last 24 hours.

![The Verify step of Setup confirming the tag is live on both Payments platform domains.](https://docs.scriptmonitoring.com/screenshots/setup-verify-light.webp)

| Tile | What it counts |
| --- | --- |
| **Delivered** | Tag requests served this month. |
| **Reporting** | Domains reporting, out of the team's active domains. |
| **Received** | Script reports that landed in the last 24 hours. |
| **PCI scope** | The number of payment page selectors. Shown with **Both** only. |

A note under the tiles sums it up: **Live across the site** or **Live, narrowly** (PCI DSS) when reports arrive, **Nothing has arrived yet** before the first visit, **Delivered, but never activated** when the tag is served but nothing reports, or **Setup is not complete** when step 4 has a blocking problem. **Per-domain** lists each domain with its first report and a status: **Receiving**, **Not receiving**, or **Crawled** for Agentic crawler domains. Domains that a payment page selector matches carry a **Payment page** badge. Suspended domains are left out.

The first report arrives within a minute of a visit to a page with the tag. For what each status means and how to fix it, see [Verify it's working](https://docs.scriptmonitoring.com/verify/).

## Frequently asked questions

### Do I have to finish Setup in one go?

No. Every answer is saved as soon as you pick it, and the stepper lets you jump to any step. A step shows a check once it is done, so you can come back later and see what is left.

### If I change the use case later, do I need to reinstall the tag?

No. The tag is the same for every use case. The use case only decides which pages report, so you can change it in step 1 at any time without touching your site.

### Why are the choices greyed out for me?

Only Super admins and Admins of the team can change Setup. Viewers see every step, can copy the snippet and test a URL, but cannot change the answers, the selectors or the Advanced settings.

### Why does Verify say "Delivered, but never activated"?

The tag was served this month but no script report arrived in the last 24 hours. Check that the tag is in the served HTML. On a single-page app, test a real URL in step 4. See [Verify it's working](https://docs.scriptmonitoring.com/verify/) for each status.

### Is Setup per domain or per team?

Per team. The script URL carries the team ID, so every domain in the team uses the same tag and the same answers. CSP reporting is the one thing set up per domain, from **Set up CSP reporting** in step 3.

## Related

- [Install the script tag](https://docs.scriptmonitoring.com/install/)
- [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)
- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/)

---

# Diagnostics

> Use Diagnostics to see whether each domain's Scripts, CSP Violations and Security Headers streams are receiving data, and stop false alarms on quiet sites.

Source: https://docs.scriptmonitoring.com/diagnostics/ · Plan: All plans · Updated 2026-10-13

**Developers > Diagnostics** answers "is the monitoring itself working?" It lists every domain in the team (or the domain picked in the top bar) with one status per data stream, flags streams that have gone quiet for longer than your failure window, and lets you mute streams that are quiet on purpose. Every team member can see it.

## How do I read Diagnostics?

Open **Developers > Diagnostics**, or click **Done, go to Diagnostics** at the end of Setup.

![Diagnostics for Payments platform: 2 domains fully receiving, no streams needing attention, the failure condition set to 24 hours, and Scripts, CSP Violations and Security Headers receiving on both domains.](https://docs.scriptmonitoring.com/screenshots/diagnostics-light.webp)

The four tiles:

- **Fully receiving**: domains whose expected streams all have data.
- **Streams needing attention**: streams past the failure window. Click it to jump to the table.
- **Not instrumented**: Agentic crawler domains, which send no live streams.
- **Last ingest**: how long ago the newest data arrived, across all streams.

The **Ingest streams by domain** table has one row per domain and one column per stream your team produces.

## What does each stream mean?

| Stream | Where it comes from |
| --- | --- |
| Scripts | Script loads observed by the edge, from pages that carry the tag. A stable site keeps this stream busy even when no new script appears. |
| CSP Violations | Content Security Policy reports sent by browsers, once your server sends the [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/) headers. |
| Security Headers | Security header reports from monitored pages. The PCI DSS 11.6.1 header evidence is built from these. |

![Ingest streams by domain: checkout.northwind.com and pay.northwind.com are Receiving on Scripts, CSP Violations and Security Headers.](https://docs.scriptmonitoring.com/screenshots/diagnostics-streams-light.webp)

Each cell has one status:

- **Receiving**: data arrived within the failure window.
- **Not receiving**: no data for longer than the window. Hover to see for how long. Counted as needing attention unless the stream is muted.
- **Not set up**: no data in the last 30 days. Never counted.

## How do I stop false alarms on quiet sites?

The **Failure condition** card sets when a stream counts as needing attention: after **1h**, **6h**, **12h**, **24h** (the default), **48h** or **72h** without data. It applies to every stream in the team. Super admins and Admins of the team can change it.

For a single stream that is quiet on purpose, click **Mute** on its row: it keeps recording, stays listed as **Not receiving**, and is no longer flagged. **Unmute** reverses it. Use **Re-run checks** at the top to refresh every result now, and **Diagnose** on a row to open that domain's own Diagnostics, with hourly charts for the last 24 hours.

## Frequently asked questions

### Why does Diagnostics show a domain with no status?

Suspended domains and Agentic crawler domains send no live streams, so they are listed without status and left out of every count.

### Why does the CSP Violations stream say "Not set up"?

CSP reports come from your server's response headers, not from the script tag. Set them up with [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/).

### My site is quiet at night and streams get flagged. What should I change?

Raise the **Failure condition** window (up to 72 hours), or mute the quiet stream on that domain. A muted stream keeps recording but is not flagged.

### Does muting a stream lose data?

No. A muted stream keeps recording. It stays listed as **Not receiving** when it is quiet, but it is no longer counted as needing attention.

## Related

- [Verify it's working](https://docs.scriptmonitoring.com/verify/)
- [CSP reporting](https://docs.scriptmonitoring.com/csp-reporting/)

---

# API keys

> Reference for Developers > API keys: sm_org_ and sm_team_ key formats, the scopes each key can carry, creating and revoking keys, and who manages them.

Source: https://docs.scriptmonitoring.com/api-keys/ · Plan: All plans · Updated 2026-10-13

**Developers > API keys** holds the server-side keys for the [REST API](https://docs.scriptmonitoring.com/api/). There are two kinds: organization keys (`sm_org_…`), which act on any team in the organization, and team keys (`sm_team_…`), which act on one team. Each key carries only the scopes you give it, and its secret is shown once, when you create it. API keys are on every plan. Super admins manage organization keys, and Admins manage their own team's keys.

![API keys: a team key for Payments platform (sm_team_10937462815530...) and three organization keys (Terraform provisioning, SIEM export, Offboarding job, each shown as sm_org_ plus its key ID) with their scopes and when each was last used, under a note that the key format changed.](https://docs.scriptmonitoring.com/screenshots/api-keys-light.webp)

> **Keep API keys server-side** They can register and delete domains, and organization keys can also create and delete teams. Never ship one to the browser or a mobile bundle.

## What does a key look like?

Every key is its type prefix, a 14-digit key ID, an underscore, then the secret:

- **Organization key**: `sm_org_14829305716342_…`
- **Team key**: `sm_team_10937462815530_…`

- **Tell them apart by the prefix**: `sm_org_` is an organization key, `sm_team_` a team key. The prefix must match the key's type: a key sent with the other prefix is refused.
- **The key ID** is 14 digits and always starts with 1. It is random, so it says nothing about how many keys exist. It is not secret: the dashboard shows it.
- **The secret** is everything after the key ID and its underscore. It is shown once, when you create the key, and Script Monitoring does not store it.
- **In the dashboard** each key shows as its prefix and key ID followed by `...`, for example `sm_org_14829305716342...`. Match that against the start of the key in your secrets manager to find which key an integration uses.

Keys created before this format were revoked when it changed. The page shows a short note about this. If an integration started getting `401 unauthorized`, create a new key and deploy it.

## Who can see and manage keys?

| Role | Sees |
| --- | --- |
| Super admin | **Team API keys** for the team picked in the top bar, and **Organization API keys**. |
| Admin | **Team API keys** for their own team. |
| Viewer | No **API keys** link in the sidebar. Opening the page shows a note to ask a Super admin or Admin for a key. |

Creating and revoking keys may ask you to confirm your password, or a code sent by email, first.

## What does each key card show?

**Team API keys** shows the team's name and its number of keys. **Organization API keys** shows the organization's number of keys. Each row is one key:

| Column | What it shows |
| --- | --- |
| Key | The name, and the key's prefix and key ID, such as `sm_team_10937462815530...`. |
| Scopes | What the key may do, or "None". |
| Created | The date the key was created. |
| Last used | How long ago the key was last used, or "never". Updated at most once a minute. |

**Revoke** on a row stops that key immediately. Any integration still using it fails until you create and deploy a new one.

## Which scopes can a key carry?

The **Available scopes** card lists them:

| Scope | What it allows | Key type |
| --- | --- | --- |
| Create teams | Create teams in this organization via `POST /v1/teams`. Pro and Enterprise. | Organization |
| Delete teams | Permanently delete teams and all their domains. | Organization |
| Register domains | Register managed domains via `POST /v1/domains`. | Team and organization |
| Delete domains | Remove registered domains via `DELETE /v1/domains`. | Team and organization |
| Add payment pages | Add payment-page selectors via `POST /v1/payment-pages`. | Team and organization |
| List teams | Read-only listing via `GET /v1/teams`. | Organization |
| List domains | Read-only listing via `GET /v1/domains`. | Team and organization |

## What is in the Create key sheet?

![The Create key sheet: name the key and pick its scopes, such as Create teams, Register domains or List domains.](https://docs.scriptmonitoring.com/screenshots/api-key-create-sheet-light.webp)

**Create key** on a card opens the sheet:

- **Name**: what uses the key, for example "Terraform provisioning".
- **Scopes**: a switch for each scope the key type allows. Pick at least one.

**Create key** creates it and opens **Key created** with the full key, for example `sm_org_14829305716342_…`. "This is the only time you will see it": **Copy** or **Download** it, then click **Done**. The secret is never shown again. Use the key only from your backend, as the Bearer token for the REST API:

```shell
curl https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer sm_org_14829305716342_…"
```

## What does Revoke all do?

**Revoke all**, at the bottom of **Organization API keys**, stops every key for the organization at once, including every team's keys. Your integrations fail until you create and deploy a new key. Only Super admins see it.

## Frequently asked questions

### What is the difference between a team key and an organization key?

A team key acts on one team only: its domains and payment pages. An organization key can act on any team in the organization, and can also create, list and delete teams. Super admins manage organization keys; Admins manage their own team's keys.

### I lost my key. Can I see it again?

No. The full key, with its secret, is shown once, when you create it. The list only shows its prefix and key ID. Revoke the lost key and create a new one.

### My old key stopped working. Why?

The key format changed, and every key that doesn't start with `sm_org_` or `sm_team_` was revoked at the change, with no grace period. That includes keys with any other prefix and keys with no prefix at all. They now get `401 unauthorized`. Create a new key under **Developers > API keys** and deploy it in place of the old one.

### Do keys expire?

No. A key works until you revoke it, or until a Super admin uses **Revoke all**.

### Why is "Create teams" locked?

Creating teams with the API is included in Pro and Enterprise. The scope shows a **Pro and Enterprise** lock when no team in the organization has a plan that includes it.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Register domains](https://docs.scriptmonitoring.com/api/domains/create/)

---

# Emergency stop

> Reference for Developers > Emergency stop: pause or resume Script Monitoring for a team, who can do it, and what keeps running while it is on.

Source: https://docs.scriptmonitoring.com/emergency-stop/ · Plan: All plans · Updated 2026-10-13

**Developers > Emergency stop** pauses or resumes Script Monitoring for one team. While it is on, the team's automatic script URLs serve an empty monitoring script, so pages on every domain in the team are not monitored. It was called Developer Mode before. It is a switch for the monitoring itself: it does not block, remove or change any other script on your pages.

![Emergency stop: monitoring is live for Payments platform. Stop monitoring pauses Script Monitoring on every domain in the team at once.](https://docs.scriptmonitoring.com/screenshots/emergency-stop-light.webp)

## What states can it be in?

| Status | Meaning |
| --- | --- |
| Monitoring live | Script Monitoring is running normally for the team. |
| Stopped | Emergency stop is on. Script Monitoring is paused for this team, and a banner across the dashboard says **Emergency stop is on.** |

## How do I stop monitoring?

1. Open **Developers > Emergency stop**. The **Status** card says **Monitoring live**.
2. Click **Stop monitoring**.
3. Read the confirmation, "Stop monitoring for this team?", and click **Stop monitoring**.
4. The status changes to **Stopped**, and the banner appears across the dashboard.

## How do I resume?

Click **Resume monitoring**, either on the Emergency stop page or in the banner, and confirm. Then check [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/): the Scripts stream returns to **Receiving** as pages are visited.

## What changes while it is on?

- The team's automatic script URLs serve an empty monitoring script, so pages that load them are not monitored.
- Stopping takes effect once the change reaches the Script Monitoring edge, and so does resuming.

## What stays the same?

- The tag stays on your pages. You do not need to deploy anything to stop or resume.
- Pinned immutable scripts keep their original behavior until you change or remove the installed script.
- Nothing is deleted. Your settings and data stay in the dashboard.
- Other teams are not affected: Emergency stop applies to one team.
- There is no timer. Monitoring stays paused until someone resumes it.

## Who can use Emergency stop?

Super admins and Admins of the team. Viewers see the page with "Only Super admins and Admins of this team can stop or resume monitoring."

## Frequently asked questions

### Does Emergency stop block scripts?

No. It pauses Script Monitoring for the team. It does not block or remove anything on your pages. To stop a script from loading, use [Blocks](https://docs.scriptmonitoring.com/blocks/).

### Does Emergency stop delete anything?

No. Nothing is deleted, and you can resume monitoring at any time.

### Does it remove the tag from my site?

No. The tag stays on your pages. While Emergency stop is on, the team's automatic script URLs serve an empty monitoring script, so those pages are not monitored.

### What about immutable scripts?

Pinned immutable scripts keep their original behavior until you change or remove the installed script. Emergency stop does not affect them.

### Is there a timer?

No. Emergency stop stays on until someone resumes monitoring.

### Monitoring resumed but Diagnostics still says Not receiving.

The change reaches the Script Monitoring edge first, then pages have to be visited. The Scripts stream turns **Receiving** as reports arrive.

## Related

- [Diagnostics](https://docs.scriptmonitoring.com/diagnostics/)
- [Install the script tag](https://docs.scriptmonitoring.com/install/)

---

# Usage

> Reference for Account > Usage: page views this month, plan utilization, the month-end projection, daily page views and the split by domain.

Source: https://docs.scriptmonitoring.com/usage/ · Plan: All plans · Updated 2026-10-13

**Account > Usage** shows how many page views the team in the top bar used this calendar month, how that compares with its plan, and where the month is heading. Page views are the only thing metered. Scripts, domains, alerts and blocks are unlimited on every plan. Metering resets on the 1st, so this page always shows the current month, not the top bar's date range.

![Usage for Payments platform: page views this month against the 100K plan, utilization, the projection at month end, daily page views and the split by domain.](https://docs.scriptmonitoring.com/screenshots/usage-light.webp)

## What do the tiles show?

| Tile | What it shows |
| --- | --- |
| Page views this month | Page views counted for the team since the 1st, against the plan's included page views. Plans with no cap show **Unlimited on your plan**. |
| Plan utilization | The share of the included page views used so far, with a bar. The bar turns red once usage passes the plan. Plans with no cap show **Unlimited**. |
| Projected at month end | A straight-line projection from this month's pace: **Within plan**, or how many page views over plan, and the date metering resets. |

## What do the chart and table show?

**Daily page views** draws one point per day this month. On a plan with a cap, a dashed line shows the plan pace: the included page views divided by the days in the month. Before the first day is recorded, the card says **No daily page views recorded this month yet.**

**By domain** lists each of the team's domains this month, busiest first:

| Column | What it shows |
| --- | --- |
| Domain | The domain. |
| Page views | Page views counted for that domain this month. |
| Share | The domain's share of the team's page views, as a bar and a percentage. |

A team with no domains shows **No domains yet.** with an **Add a domain** link.

## What warnings can appear?

Usage warnings appear on Home, Usage and Billing, and as a strip under the top bar on other pages. The strip has a dismiss button. A dismissed strip stays hidden for that team and month, and comes back when the warning changes or a new month starts.

| Plan | When | Message |
| --- | --- | --- |
| Free | At 80% of 1,000 page views | You have used a percentage of your free page views this month. |
| Free | At 1,000 page views | You passed 1,000 page views this month. Data pages are replaced by **You have reached the Free plan limit**. |
| Pro | At 80% of the included page views | You have used a percentage of your page views. Move up a plan to avoid overage. |
| Pro | Past the included page views | You are past your plan's page views, so overage applies. |

Each warning has an **Upgrade** button that opens the plan sheet. On the largest self-serve Pro volume, the button is **Talk to an expert** instead, because Enterprise has custom limits. When no warning is showing but the projection passes the plan, Usage adds its own note: **On track to exceed your plan**, with the projected overage and the date to move up a plan by. What each plan includes is on [Plans](https://docs.scriptmonitoring.com/plans/).

## Who can see Usage?

Every member of the team can open **Account > Usage**. The **Billing** button at the top opens [Billing](https://docs.scriptmonitoring.com/billing/), which needs a Super admin, an Admin with **Can manage billing**, or an Admin of the team.

## Frequently asked questions

### What counts toward my usage?

Only page views. Scripts, domains, alerts and blocks are unlimited on every plan.

### When does usage reset?

On the 1st of each month. The page always shows the current calendar month, not the top bar's date range.

### What happens when a Free team reaches 1,000 page views?

Free stops at 1,000 page views a month. Home, Alerts, Vendors, the script pages and PCI DSS show **You have reached the Free plan limit** in place of data, with an **Upgrade** button. See [Plans](https://docs.scriptmonitoring.com/plans/).

### What happens when a Pro team goes past its page views?

Overage applies. The Usage page warns you before it happens, when the projection passes the plan, so you can move up a volume in time.

## Related

- [Plans](https://docs.scriptmonitoring.com/plans/)
- [Billing](https://docs.scriptmonitoring.com/billing/)
- [Teams](https://docs.scriptmonitoring.com/teams/)

---

# Plans and upgrades

> What Free, Pro and Enterprise include, how page views are metered, the 14-day Pro trial, the plan sheet, and how to request an Enterprise proof of concept.

Source: https://docs.scriptmonitoring.com/plans/ · Plan: All plans · Updated 2026-10-13

Script Monitoring has three plans: **Free**, **Pro** and **Enterprise**. Every plan is metered on page views, and domains, scripts and vendors are unlimited on all of them. Free covers 1,000 page views a month. Pro adds volume from 100,000 to 1,000,000 page views a month, plus AI, the vendor load chain, webhooks, S3 and multiple teams. Enterprise adds custom limits, 90 days of history, SSO, audit logs and multiple organizations. Each team has its own plan. Prices are on the [pricing page](https://www.scriptmonitoring.com/pricing/).

## What does each plan include?

| Feature | Free | Pro | Enterprise |
| --- | --- | --- | --- |
| Page views a month | 1,000 (hard stop) | 100,000 to 1,000,000 | Custom |
| Domains, scripts and vendors | Unlimited | Unlimited | Unlimited |
| Script blocking and monitor-only mode | Yes | Yes | Yes |
| CSP reporting | Yes | Yes | Yes |
| PCI DSS 6.4.3 and 11.6.1 dashboard | Yes | Yes | Yes |
| PDF evidence packs, retained 18 months | Yes | Yes | Yes |
| Email alerts | Yes | Yes | Yes |
| API keys | Yes | Yes | Yes |
| MFA enforcement | Yes | Yes | Yes |
| Script history | 30 days | 30 days | 90 days |
| AI script analysis and PCI auto-approval | No | Yes | Yes |
| Vendor load chain | No | Yes | Yes |
| Per-vendor permissions | No | Yes | Yes |
| Webhook alerts and S3 log push | No | Yes | Yes |
| Multiple teams | No | Yes | Yes |
| SSO | No | No | Yes |
| Audit logs | No | No | Yes |
| Multiple organizations | No | No | Yes |
| 99.9% uptime SLA | No | No | Yes |
| Priority support under 4 business hours | No | No | Yes |

Each docs page shows the lowest plan that includes what it describes. In the dashboard, a feature your plan doesn't include shows a lock with the plan it needs (**Pro** or **Enterprise**). Clicking it opens the plan sheet with the reason.

## How are page views metered?

Page views are counted per team, per calendar month, and reset on the 1st. They are the only thing metered. [Usage](https://docs.scriptmonitoring.com/usage/) shows this month's count, the projection and the split by domain.

- **Free** is a hard stop at 1,000 page views. At the limit, Home, Alerts, Vendors, the script pages and PCI DSS show **You have reached the Free plan limit** in place of data, with an **Upgrade** button.
- **Pro** includes the page views of its volume. Past that, overage applies.
- **Enterprise** has custom limits.

Warnings appear at 80% of the allowance, as described on [Usage](https://docs.scriptmonitoring.com/usage/).

## What does the plan sheet show?

The plan sheet opens from **Upgrade** or **Change plan** on [Billing](https://docs.scriptmonitoring.com/billing/), from a usage warning, from a plan lock, or from **Upgrade to Pro** in the command palette. On Free it is titled **Upgrade your team**. On a paid plan it is **Manage your subscription**, and the team's plan carries a **Current plan** badge.

![The Upgrade your team sheet on the Free plan: Pro, billed monthly or annually with a 15% saving, with a page view picker and a free trial, or Enterprise with custom terms.](https://docs.scriptmonitoring.com/screenshots/upgrade-sheet-light.webp)

- **Monthly** and **Annual** tabs set the billing period. The Annual tab shows the saving.
- The **Pro** card has a **Page views a month** picker with ten volumes, from up to 100,000 to up to 1,000,000, each with its price. Volumes above 500,000 are set up by our team, so picking one turns the button into **Talk to an expert**. Above 1,000,000 page views, pricing is custom.
- The **Enterprise** card shows **Custom** pricing.
- The **Free** card appears only when you manage a paid plan, so you can downgrade.

The footer sums up the change, such as "Changing to Pro, 200,000 page views a month, billed monthly." The button reads **Upgrade**, **Start the trial**, **Change plan**, **Downgrade** or **Talk to an expert**, depending on what you picked. When upgrading, the sheet only offers plans above the current one.

![The Manage your subscription sheet: the Pro plan at $99 a month for 100,000 page views, with a page view picker, and Enterprise with custom terms.](https://docs.scriptmonitoring.com/screenshots/plan-sheet-light.webp)

## How does the Pro trial work?

A Free team that has never had a trial gets a 14-day free trial of Pro. The Pro card shows **14-day free trial**, and the button reads **Start the trial**. During the trial, [Billing](https://docs.scriptmonitoring.com/billing/) shows the **Trial** status and the date it ends. Add a card before then to keep the plan. Moving to Free during a trial ends the trial at once.

## How do I request Enterprise?

Pick **Enterprise** and click **Talk to an expert**. The sheet moves to **Request Enterprise access**, a request for a 14-day proof of concept:

![Request Enterprise access: your monthly traffic, a few questions about the proof of concept (single-page app, needed-by date, use case) and Submit request.](https://docs.scriptmonitoring.com/screenshots/poc-sheet-light.webp)

- **Your traffic**: **Page views a month** or **Transactions a month**. An estimate is fine. When the team's usage or the picked volume is known, it is filled in, with an **Edit** button.
- **The POC**: **Is your site a single-page application (SPA)?** (**Yes**, **No** or **Not sure**), **Needed by**, and **Use case** (**PCI DSS 6.4.3 & 11.6.1**, **Client-side security** or **Both**).
- **Anything else?**: optional notes. Left empty, we ask about the domains and payment pages to cover, who else joins the evaluation, and your compliance deadline.

**Submit request** sends it. The confirmation says we will contact you by email within one business day to set up the proof of concept. You can also [talk to an expert](https://www.scriptmonitoring.com/contact/) on our website.

## Who can change a plan?

Super admins, Admins with **Can manage billing**, and Admins of the team can change that team's plan.

## Frequently asked questions

### What happens when Free reaches 1,000 page views?

Free is a hard stop at 1,000 page views a month. Home, Alerts, Vendors, the script pages and PCI DSS show **You have reached the Free plan limit** in place of data until you upgrade or the month resets on the 1st.

### Is there a free trial of Pro?

Yes. A Free team that has never had a trial gets 14 days of Pro. The plan sheet shows **14-day free trial** and the button reads **Start the trial**.

### Are blocking, CSP and evidence packs paid features?

No. Script blocking, CSP reporting, the PCI DSS dashboard and PDF evidence packs are on every plan, including Free.

### How long is an Enterprise proof of concept?

14 days. Request one from the plan sheet with **Talk to an expert**, or [contact us](https://www.scriptmonitoring.com/contact/).

### Where are the prices?

On the [pricing page](https://www.scriptmonitoring.com/pricing/). The plan sheet shows the price for the volume and billing period you pick.

## Related

- [Billing](https://docs.scriptmonitoring.com/billing/)
- [Usage](https://docs.scriptmonitoring.com/usage/)
- [Teams](https://docs.scriptmonitoring.com/teams/)

---

# Organization

> Reference for Settings > Organization: the name, ID, primary contact and data retention, plus single sign-on, required MFA and the audit log.

Source: https://docs.scriptmonitoring.com/organization/ · Plan: All plans · Updated 2026-10-13

**Settings > Organization** holds the settings that apply to every team in your organization: its name and ID, the primary contact, data retention, single sign-on, required MFA and the audit log. Super admins can change them. MFA enforcement is on every plan, while single sign-on and audit logs are on Enterprise.

![Organization settings for Northwind Retail Group: name, organization ID, primary contact, data retention, single sign-on and MFA requirements.](https://docs.scriptmonitoring.com/screenshots/organization-light.webp)

## What does the Details card show?

| Row | What it shows |
| --- | --- |
| Organization name | The organization's name. **Rename** changes it, and the new name also appears on future invoices. |
| Organization ID | The organization's ID. |
| Primary contact | The email address of the organization's owner. |
| Data retention | How many days of history the organization keeps: the longest of its teams' plans (30 days on Free and Pro, 90 on Enterprise). With more than one team, it adds **The longest of your team plans.** |

## What does the Access card show?

### Single sign-on

The status is **Enabled** with the provider (SAML 2.0, or an OIDC provider such as Okta, Microsoft Entra ID, Google Workspace or Duo), or **Not set up**. **Configure** opens the single sign-on settings. SSO is on Enterprise: without it, the row shows **Available on Enterprise** with a lock, and **Configure** opens the plan sheet.

### Require MFA

The switch requires multi-factor authentication for every member of the organization. Next to it: how many members are enrolled and how many are not, and how many grace days are left once enforcement is on.

Turning it on asks for an **Enforcement mode**:

| Mode | What members without MFA see |
| --- | --- |
| Banner | A banner until they set it up. |
| Lockout | They are locked out of the dashboard until they set it up. |

Members get a 14-day grace period to set up MFA. People who join later get their own 14 days.

Under the switch, **Or require it for single teams** lists each team with its own mode picker (**Banner** or **Lockout**) and switch. To change a team's mode, turn its enforcement off and on again, which restarts the grace period. When the organization rule is on, the list says **Every team is covered by the organization rule.**

### Audit log

**Every change is recorded.** **View audit log** opens the audit logs. Audit logs are on Enterprise, so the row shows an **Enterprise** lock on other plans.

## Who can use Organization?

Super admins see **Organization** in the sidebar and can rename the organization, configure single sign-on and require MFA. Other members who open the page see it read-only, without the per-team MFA list, and the **Require MFA** switch shows **Only Super admins can change this**.

## Frequently asked questions

### Why does Data retention show 90 days when one team is on Pro?

The organization keeps the longest retention of its team plans. With more than one team, the row says **The longest of your team plans.**

### Can I require MFA on the Free plan?

Yes. MFA enforcement is on every plan. SSO and audit logs are Enterprise.

### What is the difference between Banner and Lockout?

With **Banner**, members without MFA see a banner until they set it up. With **Lockout**, they are locked out of the dashboard until they set it up. Either way they get a 14-day grace period first.

### Who can change these settings?

Super admins. Other members can open the page, but the controls are read-only for them.

## Related

- [Teams](https://docs.scriptmonitoring.com/teams/)
- [Billing](https://docs.scriptmonitoring.com/billing/)
- [Plans](https://docs.scriptmonitoring.com/plans/)

---

# Teams

> Reference for Settings > Teams: every team in the organization with your role, its domains and open alerts, how to switch teams, and who can add one.

Source: https://docs.scriptmonitoring.com/teams/ · Plan: All plans · Updated 2026-10-13

**Settings > Teams** lists the teams in your organization, with your role in each, its domains and its open alerts. A team owns its own domains, members and billing line, and switching team changes which domains you see everywhere else. Every plan includes one team. Multiple teams are on Pro and Enterprise.

![Teams in Northwind Retail Group: Payments platform and Marketing sites with your role, their domains and open alerts.](https://docs.scriptmonitoring.com/screenshots/teams-light.webp)

## What does the table show?

The header shows how many teams there are and how many you are a member of. A note above it says which teams you see: every team, if you are a Super admin or can manage billing, or only the teams you belong to.

| Column | What it shows |
| --- | --- |
| Team | The team name, with a **Current** badge on the team in the top bar, and its domains underneath (or **No domains yet**). |
| Your role | **Super admin**, **Admin** or **Viewer**, or **Not a member** for a team you can see but have not joined. |
| Domains | How many domains the team has. |
| Open alerts | The team's open alerts. |

With no team to show, the page says **No teams visible** and asks you to have a Super admin add you to a team.

## What are the row actions?

- **Switch to** opens the team's Home. On the current team, the row says **You are here**.
- **Open** or **Open as Super admin** appears instead of **Switch to** on a team you can see but have not joined.
- **Manage** renames the team.

## How do I add a team?

**New team** opens **Create a team**: a **Team name** and a **Plan** (**Free**, **Pro** or **Enterprise**). **Free** is always available. **Pro** and **Enterprise** are available when your organization has plans allocated to it, with how many are used. **Create team** creates it.

On Free, **New team** shows a **Pro** lock and opens the plan sheet with "Multiple teams are on Pro and Enterprise." What each plan includes is on [Plans](https://docs.scriptmonitoring.com/plans/).

## Who can use Teams?

Every member can open **Settings > Teams**. Super admins can add teams with **New team** and rename them with **Manage**.

## Frequently asked questions

### What does a team own?

Its own domains, members and billing line. Switching team in the top bar changes which domains you see everywhere else in the dashboard.

### Why is New team locked?

Multiple teams are on Pro and Enterprise. On Free, **New team** shows a **Pro** lock and opens the plan sheet. A team on Pro or Enterprise unlocks it for the whole organization.

### Why do I see teams I have not joined?

Super admins and Admins with **Can manage billing** see every team in the organization. Admins and Viewers see only the teams they belong to.

### Can I create teams with the API?

Yes, on Pro and Enterprise, with an organization API key (`sm_org_…`). See [Create a team](https://docs.scriptmonitoring.com/api/teams/create/).

## Related

- [Organization](https://docs.scriptmonitoring.com/organization/)
- [Create a team (API)](https://docs.scriptmonitoring.com/api/teams/create/)
- [Plans](https://docs.scriptmonitoring.com/plans/)

---

# Members

> Reference for Settings > Members: the Super admin, Admin and Viewer roles, team access, MFA status, invitations, and who can change access.

Source: https://docs.scriptmonitoring.com/members/ · Plan: All plans · Updated 2026-10-13

**Settings > Members** lists everyone in your organization with their role, the teams they can reach and whether they use MFA. There are three roles: **Super admin**, **Admin** and **Viewer**. Super admins invite people, change roles and remove access here. Everyone else in the organization can open the page and see it read-only.

![Members: people in Northwind Retail Group with their organization role (Super admin, Admin, Viewer), team access and MFA, plus access by team.](https://docs.scriptmonitoring.com/screenshots/members-light.webp)

## What does the People table show?

The **People** card counts the people in the organization and any pending invitations. Each row is one person or one invitation.

| Column | What it shows |
| --- | --- |
| Person | Name and email. Your own row says "(you)". An invitation shows the email and "Invitation pending". |
| Organization role | **Super admin**, **Admin** or **Viewer**, plus a **Billing** tag for an Admin who can manage billing. |
| Team access | One chip per team with the role in that team. A Super admin with no team role reads "Sees every team, edits through the organization". Otherwise "No team access", or "No team yet" for an invitation. |
| MFA | **Enrolled**, **Not enrolled**, or **Invited** for a pending invitation. |
| Actions | **Manage access** on people, **Resend invitation** and **Revoke invitation** on invitations. Anyone who is not a Super admin sees "View only". |

## What do the roles mean?

| Role | What it can do |
| --- | --- |
| Super admin | Everything: every team, billing, members and settings. |
| Admin | Changes things in the teams they are given. |
| Viewer | Read only in the teams they are given. |

An Admin can also have **Can manage billing**: plans, payment methods and invoices for the organization. Billing is not a separate role. It shows as **Admin** with a **Billing** tag, and it can be held without any team access.

A person with Admin in one team and Viewer in another shows as **Admin**, their strongest role. The **Team access** chips show the role in each team.

## What does Access by team show?

The **Access by team** card lists each team with who can change things and who can only look:

- **Team**: the team name, with your own role in it ("You: Admin" or "You: Viewer").
- **Admins**: first names of the team's Admins, or a **None** warning.
- **Viewers**: first names of the team's Viewers, or "None".

A team whose members you cannot see reads "Not visible to you". Super admins get **Edit access** on each row. It opens a sheet that lists everyone in the team with **Admin**, **Viewer** or **Remove from team**, and a **Save** button.

## What warnings can appear?

Two notes can appear at the top of the page:

- **"1 member has not enrolled in MFA."** (or the count). If your organization requires MFA, they are prompted at their next sign-in. If not, the note points to **Settings, Organization**. See [MFA](https://docs.scriptmonitoring.com/mfa/).
- **"1 team has no Admin."** (or the count), followed by the team names. Only a Super admin can approve a vendor or block a script in those teams.

## What is in the Invite people sheet?

**Invite people** opens a sheet. People you invite get an email with a link to join.

![The Invite people sheet: email addresses, a role (Super admin, Admin or Viewer), whether they can manage billing, and the team.](https://docs.scriptmonitoring.com/screenshots/invite-member-sheet-light.webp)

| Field | What it does |
| --- | --- |
| Email addresses | One or more addresses, separated by commas, spaces or semicolons. Up to 50 at a time. |
| Role | **Super admin**, **Admin** (the default) or **Viewer**. |
| Can manage billing | Shown for **Admin**. Gives billing rights for the organization. |
| Team | The one team they join. Hidden for a Super admin. An Admin with billing can pick **No team access**. |

**Send invites** sends the emails. You cannot invite yourself or a disposable email address. On plans without SSO, the sheet also links to [single sign-on](https://docs.scriptmonitoring.com/sso/), which is on Enterprise.

On a pending invitation, **Resend invitation** sends the email again. **Revoke invitation** asks you to confirm first: the invite link stops working, and adding the person later takes a new invitation.

## What can I change with Manage access?

**Manage access** opens a sheet with the person's name, email and current role:

- **Role**: **Super admin**, **Admin** or **Viewer**, with **Can manage billing** under Admin. Picking Admin or Viewer applies it to every team they hold.
- **Team access**: one menu per team they belong to, with **Admin**, **Viewer** or **Remove from team**. Hidden when you pick Super admin.
- **Remove from organization** removes the person from the organization. It does not show on your own row.

**Save** applies the changes.

## Who can manage members?

Only Super admins see **Invite people**, **Manage access** and **Edit access**. Admins, Admins with billing and Viewers see the page read-only, with "View only" in the actions column.

## Frequently asked questions

### What is the difference between a Super admin and an Admin?

A Super admin can do everything: every team, billing, members and settings. An Admin changes things only in the teams they are given. A Viewer can only look, in the teams they are given.

### How do I give someone access to billing?

Make them an **Admin** and turn on **Can manage billing**. They then manage plans, payment methods and invoices for the organization. They can have this with **No team access**.

### How do I add an existing member to another team?

Send them another invitation from **Invite people** and pick the other team. **Manage access** changes or removes the team roles they already have.

### What happens when a team has no Admin?

The page warns you. Only a Super admin can approve a vendor or block a script in that team until it has an Admin again.

## Related

- [MFA](https://docs.scriptmonitoring.com/mfa/)
- [SSO](https://docs.scriptmonitoring.com/sso/)
- [Audit logs](https://docs.scriptmonitoring.com/audit-logs/)

---

# Single sign-on (SSO)

> Reference for single sign-on: where to configure it, the Okta, Duo, Microsoft Entra ID and SAML 2.0 fields, how people sign in, and who can change it.

Source: https://docs.scriptmonitoring.com/sso/ · Plan: Enterprise · Updated 2026-10-13

Single sign-on lets people with your company's email domain sign in to Script Monitoring through your identity provider. It is set up in **Settings > Organization**, in the **Single sign-on** row of the **Access** card. It works with Okta, Duo Security and Microsoft Entra ID over OpenID Connect, and with any SAML 2.0 provider. SSO is on Enterprise, and only Super admins can configure it.

![Organization settings for Northwind Retail Group: name, organization ID, primary contact, data retention, single sign-on and MFA requirements.](https://docs.scriptmonitoring.com/screenshots/organization-light.webp)

## What does the Single sign-on row show?

The row shows **Enabled** with the provider (for example "SAML 2.0", "Okta OIDC", "Microsoft Entra ID OIDC" or "Duo OIDC"), or **Not set up**.

**Configure** opens the **Single sign-on** sheet. If no team in the organization is on Enterprise and SSO is not set up, the row reads "Available on Enterprise" and **Configure** opens the upgrade sheet instead.

## Which identity providers can I pick?

The sheet starts by asking for your identity provider. A provider you already set up shows a **Set up** badge.

| Option | How it connects |
| --- | --- |
| Okta | OpenID Connect with a client ID and secret. |
| Duo Security | OpenID Connect with a client ID and secret. |
| Microsoft Entra ID | OpenID Connect with a client ID and secret. |
| Any SAML 2.0 provider | Upload your identity provider's metadata. |

**Continue** opens the configuration step. **Back** returns to the list. SAML 2.0 is turned on per organization. If it is missing, [contact us](https://www.scriptmonitoring.com/contact/).

If Script Monitoring set up your SSO for you, the sheet says "Your organization's single sign-on is managed by Script Monitoring. Contact support to make changes."

## What does an OpenID Connect provider need?

| Field | What to enter |
| --- | --- |
| Email domain | People with this email domain sign in with SSO, for example `example.com`. |
| Okta endpoint, Duo endpoint or Entra tenant ID | Your provider's identifier, for example `trial-9849483.okta.com` for Okta. The label changes with the provider. |
| Client ID | The client ID of the app you created in your provider. |
| Client secret | The client secret. When editing, leave it blank to keep the existing one. |

The footer has **Test connection**, **Save** and, once configured, **Remove**. The first save, and any save that changes the email domain, asks you to verify: you sign in with your identity provider in a popup window, so allow popups for the dashboard.

## What does SAML 2.0 need?

The SAML step first shows two values to paste into the SAML application in your identity provider, each with a copy button:

- **Assertion Consumer Service (ACS) URL**
- **Service provider entity ID (Audience)**

Then it asks for:

| Field | What to enter |
| --- | --- |
| Email domain | Separate several domains with commas. A domain can only be claimed by one SSO configuration. |
| Metadata URL | **Identity provider metadata URL**. Preferred: signing certificates can be refreshed from it when your provider rotates them. |
| Paste metadata XML | **Identity provider metadata XML**, for providers that offer a download instead of a URL. Paste updated metadata when certificates rotate. |

**Save SAML configuration** saves it. A saved configuration shows the **Identity provider**, the **Sign-on URL** and the number of **Active signing certificates**. **Refresh certificates** (with a metadata URL only) re-reads the certificates, and **Remove SAML** removes the configuration.

## How do people sign in with SSO?

On the sign-in page, people click **Single sign-on (SSO)**, enter their work email and click **Continue with SSO**. Script Monitoring sends them to the identity provider that owns their email domain.

## Who can configure SSO?

Super admins. Other roles do not see **Configure**. Setting up or changing SSO needs at least one team in the organization on Enterprise. Removing a configuration and signing in with one work on any plan.

## Frequently asked questions

### Which identity providers are supported?

Okta, Duo Security and Microsoft Entra ID over OpenID Connect, and any SAML 2.0 identity provider.

### I don't see the SAML 2.0 option. Why?

SAML 2.0 is turned on per organization. If it is not in the list, [contact us](https://www.scriptmonitoring.com/contact/) to turn it on.

### What happens if we leave Enterprise?

Setting up or changing SSO needs Enterprise. Signing in with an existing configuration and removing it do not, so nobody is locked out after a plan change.

### What happens when I remove SSO?

People in your organization can no longer sign in with SSO. They sign in with their password instead.

## Related

- [MFA](https://docs.scriptmonitoring.com/mfa/)
- [Members](https://docs.scriptmonitoring.com/members/)
- [Audit logs](https://docs.scriptmonitoring.com/audit-logs/)

---

# Multi-factor authentication (MFA)

> Reference for MFA: authenticator apps, passkeys and backup codes in Profile, and requiring MFA for the organization or single teams, with Banner or Lockout.

Source: https://docs.scriptmonitoring.com/mfa/ · Plan: All plans · Updated 2026-10-13

Multi-factor authentication adds a second step at sign-in. Each person sets up their own methods in **Settings > Profile**: an authenticator app, a passkey, or both, plus backup codes. Super admins can require MFA for the whole organization or for single teams in **Settings > Organization**, with a 14-day grace period and a **Banner** or **Lockout** mode. Both are on every plan.

## Which MFA methods can I set up?

On **Settings > Profile**, the **Two-factor** row shows your methods (for example "Passkey + authenticator app") or **Not set up**. **Set up** or **Manage** opens the **Two-factor authentication** card.

![Your profile: name, email, password, multi-factor authentication and sessions.](https://docs.scriptmonitoring.com/screenshots/profile-light.webp)

| Method | What it is | Controls |
| --- | --- | --- |
| Authenticator app | A 6-digit code from your authenticator app at each sign-in. Shows **On** or **Off**. | **Set up**, **Turn off** |
| Passkey | A passkey or security key, such as Touch ID or a YubiKey. Shows how many you have. | **Set up** or **Add passkey**. Each key has **Rename** and **Remove**, and **Enroll again** when it needs re-enrolling. |
| Backup codes | One-time codes for when your other methods are not at hand. Shown once you have a method. | **Export Backup Codes**, then **Regenerate Backup Codes** |

Backup codes are shown only once, with a download as a text file. Regenerating them invalidates the old ones. Adding a passkey first shows a **Biometric data notice** to acknowledge.

## What does Require MFA do?

The **Require MFA** row in the **Access** card of **Settings > Organization** has one switch for the whole organization. Next to it: how many members are enrolled ("4 of 5 members enrolled.") and, while it runs, the days of grace left.

![Organization settings for Northwind Retail Group: name, organization ID, primary contact, data retention, single sign-on and MFA requirements.](https://docs.scriptmonitoring.com/screenshots/organization-light.webp)

Turning it on opens **Enable MFA Enforcement?**, where you pick the **Enforcement mode**:

- **Persistent banner**: members without MFA see a banner nudging them to set it up.
- **Full lockout**: members without MFA are locked out of the dashboard until they enable it.

**Enable** starts a 14-day grace period. Turning it off asks you to confirm in **Disable MFA Enforcement?**.

## Can I require MFA for only some teams?

Yes. While the organization rule is off, the row reads "Or require it for single teams:" and lists every team with:

- a mode menu, **Banner** or **Lockout**, picked before you turn the rule on;
- a switch, which asks you to confirm ("Require MFA in Payments platform?").

A running rule shows its mode read-only. To change the mode, turn the rule off and on again, which restarts the grace period. When the organization rule is on, each team reads "Required by the organization".

## What do members without MFA see?

Members who already have an authenticator app or a passkey see nothing. Everyone else:

| When | What they see |
| --- | --- |
| During the grace period | A banner: "Your organization requires MFA for all members. You have 9 days to enable it." with **Set up MFA →**. |
| After it, Banner mode | The same banner, asking them to enable it as soon as possible. |
| After it, Lockout mode | A full-page **Multi-factor Authentication Required** screen with **Set up MFA**, until they set it up. |

The grace period is 14 days from when the rule was turned on or from when the person joined, whichever is later. If several rules apply to someone, the strictest wins: the earliest grace period end, and Lockout over Banner. The **MFA** column on [Members](https://docs.scriptmonitoring.com/members/) shows who is **Enrolled** and who is **Not enrolled**.

## Who can change MFA settings?

Everyone manages their own methods on [Profile](https://docs.scriptmonitoring.com/profile/). Only Super admins can require MFA for the organization or a team. For anyone else the switches are turned off with "Only Super admins can change this".

## Frequently asked questions

### Which plans can require MFA?

Every plan. Requiring MFA for the organization or for single teams is not plan-gated.

### How long do members have to set up MFA?

14 days, counted from when the rule was turned on or from when they joined, whichever is later.

### What is the difference between Banner and Lockout?

Both show a banner during the grace period. After it, **Banner** keeps the banner, and **Lockout** blocks the dashboard until the member sets up MFA.

### How do I change a team's enforcement mode?

Turn the team's rule off, pick the new mode, and turn it on again. That restarts the 14-day grace period.

## Related

- [Profile](https://docs.scriptmonitoring.com/profile/)
- [Members](https://docs.scriptmonitoring.com/members/)
- [SSO](https://docs.scriptmonitoring.com/sso/)

---

# Audit logs

> Reference for Settings > Audit logs: the columns, the scope, kind of change and person filters, which changes are recorded, and who sees which entries.

Source: https://docs.scriptmonitoring.com/audit-logs/ · Plan: Enterprise · Updated 2026-10-13

**Settings > Audit logs** lists who changed what in your organization, and when, for the top bar's date range, newest first. You can search it, filter by scope, kind of change and person, and click any row to see the details that were recorded. Audit logs are on Enterprise. Every member of the organization can open the page, and each person sees the entries for the parts of the organization they can access.

![Audit logs: who changed what in the organization and when. Audit logs are on the Enterprise plan.](https://docs.scriptmonitoring.com/screenshots/audit-logs-light.webp)

## What does each column show?

The **Activity** card has one row per change:

| Column | What it shows |
| --- | --- |
| When | The date and the local time. Hover for other time zones. |
| Who | The person's name and email. "Script Monitoring" when Script Monitoring made the change, "Deleted user" when the account no longer exists. |
| Action | What was done, and the operation under it. |
| Resource | The thing that changed (a domain, a block, a team, a person) and its kind. |
| Scope | **Organization**, **Team** or **Domain**: where the change applies. |

Click a row to expand its **Details**: the recorded data as JSON, with a copy button. A row with nothing more says "No further details were recorded for this change." **Previous** and **Next** page through long results.

## How do I filter the log?

The filter bar has:

- **Search**: matches actions, people and resources.
- **Scope**: **All scopes**, **Organization**, **Team** or **Domain**.
- **Kind of change**: **All changes** or one kind (see below).
- **Person**: **Everyone** or one member.
- **Clear filters**, once any filter is set.

The date range comes from the top bar. If nothing matches, the page says "No activity in this period".

## Which changes are recorded?

The **Kind of change** filter lists every kind the log records: **Domains**, **Blocks**, **Block overrides**, **Alert reviews**, **Scripts**, **Browser extensions**, **Teams**, **People**, **Invitations**, **Payment methods** and **Organization**. Each row's **Resource** column names its kind.

## Who can see audit logs?

Every member of the organization can open **Audit logs**, but not every entry:

- **Super admins** and **Admins with billing** see the organization and every team and domain.
- **Admins** and **Viewers** see organization entries plus the teams they belong to and the domains they can access.

If no team in the organization is on Enterprise, the page shows "Audit logs are on Enterprise" instead of the log.

## Frequently asked questions

### Which plan includes audit logs?

Enterprise. The organization gets audit logs when at least one of its teams is on Enterprise. On other plans the page shows "Audit logs are on Enterprise".

### Why does an entry say "Script Monitoring" instead of a person?

Script Monitoring made that change itself. An entry by a person whose account was deleted says "Deleted user".

### Why can't I see changes in some teams?

You see organization entries plus the teams and domains you belong to. Super admins and Admins with billing see every team.

## Related

- [Members](https://docs.scriptmonitoring.com/members/)
- [SSO](https://docs.scriptmonitoring.com/sso/)
- [MFA](https://docs.scriptmonitoring.com/mfa/)

---

# Notifications

> Reference for Settings > Notifications: every rule and when it fires, the defaults per use case, destinations and plan limits, and your own email preferences.

Source: https://docs.scriptmonitoring.com/notifications/ · Plan: All plans · Updated 2026-10-13

**Settings > Notifications** decides which Script Monitoring events reach your team and where. There is one team rule per trigger, and each rule sends to email, a webhook or an S3 bucket. Rules run on the notifications engine, so they fire whether or not anyone is signed in. To set up a rule and test it, [follow the guide →](https://docs.scriptmonitoring.com/guides/notifications/).

<Screenshot id="notifications" alt="Settings > Notifications with Your delivery, the Team rules table and Delivery destinations" eager />

## Which events can notify me?

The **Team rules** card lists every trigger, with its status (**Active**, **Paused**, **Locked**, **Not set up** or **Removed integration**) and last delivery.

| Rule | When it fires | Cadence |
| --- | --- | --- |
| Malicious script detected | The rules engine flags a malicious or suspicious script. | Immediately |
| High-risk vulnerability found | Malware, or a high or critical severity vulnerability, in a script. | Immediately |
| Vulnerable library found | A library with a known, lower-severity vulnerability. | Immediately, daily or weekly |
| Threat intelligence match | A script matches the Script Monitoring Threat Intelligence list. | Immediately |
| Data sent to a malicious destination | A page sends data to a destination on the threat list. | Immediately |
| Flagged tag manager container | A script loads a tag manager container on the threat list. | Immediately |
| New outbound connections to review | Outbound hostnames still waiting for review. | Daily or weekly |
| CSP violations digest | Scripts your Content-Security-Policy blocked. | Daily or weekly |
| Recommended CSP header changed | The recommended Content-Security-Policy for a domain changed. | Daily or weekly |
| Security headers changed | Security headers changed on a payment page. | Immediately |
| PCI evidence pack ready | A PCI DSS evidence pack is ready to download. | Daily or weekly |
| PCI vendors need review | Payment-page vendors still need a PCI DSS review. | Weekly |

**Recommended CSP header changed** needs the CSP Builder, which is not on for every team.

## Which rules are on by default?

The use case you pick in Setup step 1 sets the defaults:

| Use case | Rules turned on |
| --- | --- |
| Client-side security | Every rule except **PCI evidence pack ready** and **PCI vendors need review**. |
| PCI DSS 6.4.3 & 11.6.1 | **Security headers changed** and **PCI evidence pack ready**. |
| Both | Every rule. |

Changing the use case later updates only the rules nobody has edited. Turning a rule on from its switch emails all team members; edit it to change that.

## What does each destination need?

| Destination | Fields | Plan |
| --- | --- | --- |
| Email | **Send to all team members**, or chosen **Team members**, plus **Other addresses** for people outside the team, such as a shared security inbox. | All plans |
| Webhook | **URL**, **Signing secret** and **Format**: **JSON**, **Slack** or **Discord**. | Pro and Enterprise |
| S3 | **Bucket**, **Region** and an optional **Path prefix**. | Pro and Enterprise |

Some triggers limit the destinations: **PCI vendors need review** sends email only, and **Recommended CSP header changed** sends email or webhook.

### Webhooks

Script Monitoring posts each alert to your URL, signed with your **Signing secret**. How to verify the signature, and what the payload looks like: [Webhooks](https://docs.scriptmonitoring.com/webhooks/).

### S3

Script Monitoring writes alerts to your bucket as hourly CSV files named `alerts-team-<teamID>-<from>-<to>.csv`, under the path prefix. Your bucket policy must let Script Monitoring write to it.

## What about my own email preferences?

**Your delivery** applies to your account only: **Organization, team and script emails**, **Security emails** and **Marketing emails**.

## Frequently asked questions

### Do rules need someone signed in?

No. Team rules run on the notifications engine, so they fire whether or not anyone is signed in.

### Why can't I pick S3 or a webhook for some rules?

Some triggers limit their destinations: **PCI vendors need review** sends email only, and **Recommended CSP header changed** sends email or webhook. Webhook and S3 also need Pro or Enterprise.

## Related

- [Set up notifications (guide)](https://docs.scriptmonitoring.com/guides/notifications/)
- [Webhooks](https://docs.scriptmonitoring.com/webhooks/)
- [Alerts](https://docs.scriptmonitoring.com/alerts/)

---

# Billing

> Reference for Settings > Billing: the team's plan card and its statuses, the organization's payment method, invoices, and who can change each.

Source: https://docs.scriptmonitoring.com/billing/ · Plan: All plans · Updated 2026-10-13

**Settings > Billing** shows the plan of the team in the top bar, the organization's payment method and the organization's invoices. Each team has its own plan, while the card and the invoices are shared by the whole organization. Change the plan from the plan card, add a card from **Payment method**, and download any invoice from **Invoices**.

![Billing for Payments platform: the Pro plan with 100,000 page views a month, the payment method and invoices.](https://docs.scriptmonitoring.com/screenshots/billing-light.webp)

## What does the plan card show?

The card's title is the plan (**Free**, **Pro** or **Enterprise**) and the team name. Below it:

- **Price**: the next charge and **per month, billed monthly** or **per year, billed yearly**. Free shows **$0 free forever**. A paid plan with nothing due shows **No upcoming charge on file.** Enterprise shows **Billed by invoice** and **Contact your account manager to make changes.** A credit on the account shows as **credit on the account**.
- **Included page views**: such as "100,000 page views a month included", or **Unlimited page views**.
- **Usage bar**: page views used this period against the included amount. It turns red past the plan. The full breakdown is on [Usage](https://docs.scriptmonitoring.com/usage/), through **View usage** at the top of the page.
- **Dates**: **Renews**, **Trial ends** or **Ends**, with the date.

### What do the statuses mean?

| Status | Meaning |
| --- | --- |
| Active | The plan is running normally. |
| Trial | The team is in its 14-day Pro trial. **Trial ends** shows the date. |
| Cancelling | The plan is set to end. **Ends** shows the date. |
| Payment overdue | An invoice needs payment. **Pay invoice** opens it. |

### What are the buttons?

- **Upgrade** (Free) opens the plan sheet on Pro and Enterprise.
- **Change plan** (Pro) opens **Manage your subscription**, where you change the page view volume, the billing period, or move to another plan.
- **Pay invoice** appears when a payment is overdue.

Enterprise plans have no plan button. How the plan sheet works is on [Plans](https://docs.scriptmonitoring.com/plans/).

## What does Payment method show?

The organization's default card: its last four digits, brand, expiry date and a **Default** badge. Under it, **Billing address** lists the card's **Address**, **City** and **Country**. With no card, the card says **No card on file.**

- **Add card** adds a card to the organization.
- **Switch** appears when the organization has more than one card, and changes the default.

When a team needs a card, a note at the top of the page says so: "*Team* needs a card on file." During a trial it asks you to add one before the trial ends to keep the plan.

## What does the Invoices list show?

The organization's invoices, newest first. The header shows how many there are. Before the first charge, the list says **No invoices yet. They appear here after the first charge.**

| Column | What it shows |
| --- | --- |
| Date | When the invoice was created. |
| Team | The team the invoice is for. |
| Amount | The invoice total. |
| Status | **Paid**, **Open**, **Draft**, **Void** or **Uncollectible**. |
| Invoice | Downloads the invoice. |

## Who can use Billing?

| Action | Who |
| --- | --- |
| Open Billing | Super admins, Admins with **Can manage billing**, and Admins of the team in the top bar |
| Change the team's plan | Super admins, Admins with **Can manage billing**, and Admins of that team |
| Add or switch the card | Super admins and Admins with **Can manage billing** |

Viewers don't see Billing in the sidebar. Usage warnings on this page show only to people who can change the plan.

## Frequently asked questions

### Is billing per team or per organization?

Both. Each team has its own plan, shown on the plan card for the team in the top bar. The payment method and invoices belong to the organization, and each invoice names its team.

### Who can change a team's plan?

Super admins, Admins with **Can manage billing**, and Admins of that team.

### Who can add or switch the card?

Super admins and Admins with **Can manage billing**.

### Why does my Enterprise plan say "Billed by invoice"?

Enterprise is set up with our team, so there is no self-serve plan change. To change limits or terms, contact your account manager or [talk to an expert](https://www.scriptmonitoring.com/contact/).

## Related

- [Plans](https://docs.scriptmonitoring.com/plans/)
- [Usage](https://docs.scriptmonitoring.com/usage/)
- [Organization](https://docs.scriptmonitoring.com/organization/)

---

# Profile

> Reference for Settings > Profile: your name, email, role, password, two-factor methods, active sessions, and how to delete your account.

Source: https://docs.scriptmonitoring.com/profile/ · Plan: All plans · Updated 2026-10-13

**Settings > Profile** is your own account: your name, email, role, password and two-factor methods, plus the sessions signed in to your account. It is the same for every organization you belong to. Everyone can open it, and it changes only your own account.

![Your profile: name, email, password, multi-factor authentication and sessions.](https://docs.scriptmonitoring.com/screenshots/profile-light.webp)

## What does the You card show?

| Row | What it shows | Action |
| --- | --- | --- |
| Name | Your name, shown to the people in your organizations. | **Edit** opens the **Your name** sheet. |
| Email | Your sign-in email, with **Verified** once confirmed. | None |
| Role | Your role in the organization you last opened, for example "Super admin · all teams", "Admin · Billing · 2 teams" or "Viewer · 1 team". | None |
| Password | Hidden. | **Change** opens the **Change password** sheet. |
| Two-factor | Your methods, for example "Passkey + authenticator app", or **Not set up**. | **Set up** or **Manage** opens the two-factor card. |

The **Two-factor authentication** card holds your authenticator app, passkeys and backup codes. Each method is described in [MFA](https://docs.scriptmonitoring.com/mfa/).

## Where are my notification preferences?

Not on Profile. A note links to **Settings, Notifications**, where how you receive alerts sits next to the team's delivery rules. See [Notifications](https://docs.scriptmonitoring.com/notifications/).

## What does Active sessions show?

Every session signed in to your account, with your current one first and then the most recent:

| Column | What it shows |
| --- | --- |
| Device | The browser and system. Hover for the full user agent. |
| IP address | The session's IP address, or "Unknown". |
| Expires | When the session ends. |

Your current session shows "Current". Every other session has **Sign out**. The card shows five sessions first; **Show all**, **Show more** and **Show fewer** change how many.

## How do I delete my account?

**Delete account** at the bottom opens **Delete your account**. It deletes your account and every organization you created, with all of its teams and data. Type `DELETE` and click **Delete my account**. This can't be undone.

## Frequently asked questions

### Where are my email notification settings?

In **Settings > Notifications**, next to the team's delivery rules. Profile links there.

### How do I sign out a session I don't recognize?

Find it under **Active sessions** and click **Sign out**. Your current session shows "Current" and cannot be signed out from here.

### What does deleting my account remove?

Your account and every organization you created, with all of its teams and data. It can't be undone.

## Related

- [MFA](https://docs.scriptmonitoring.com/mfa/)
- [Appearance](https://docs.scriptmonitoring.com/appearance/)
- [Notifications](https://docs.scriptmonitoring.com/notifications/)

---

# Appearance

> Reference for Settings > Appearance: the Light, Dark and System themes and the Comfortable and Compact row densities, saved for this browser only.

Source: https://docs.scriptmonitoring.com/appearance/ · Plan: All plans · Updated 2026-10-13

**Settings > Appearance** sets how the dashboard looks in this browser: the theme (**Light**, **Dark** or **System**) and the row density (**Comfortable** or **Compact**). Changes apply immediately. They are saved in the browser, not on your account, so nothing else in your account changes and other people are not affected. Everyone can use it.

![Appearance: choose Light, Dark or System.](https://docs.scriptmonitoring.com/screenshots/appearance-light.webp)

## Which themes can I pick?

The **Theme** card shows the current choice ("Currently: Light") and three options, each with color swatches:

| Theme | What it does |
| --- | --- |
| Light | Always the light palette. This is the default. |
| Dark | Always the dark palette. |
| System | Follows your operating system, and changes with it. |

## What does row density change?

The **Row density** card has two options:

| Density | What it does |
| --- | --- |
| Comfortable | The default row height, with room to scan. |
| Compact | Tighter table and list rows, so more fits on screen. |

## Is there a quicker way to switch?

Yes. The theme and density buttons in the top bar change the same settings without leaving the page you are on.

## Frequently asked questions

### Why is my theme different on another computer?

Appearance is saved in each browser, not on your account. Pick it once in every browser you use.

### Does my choice change the dashboard for my team?

No. It applies only to you, in this browser. Nothing else in your account changes.

### What does System do?

It follows your operating system's light or dark setting, and switches when your system does.

## Related

- [Profile](https://docs.scriptmonitoring.com/profile/)

---

# REST API

> Manage teams, domains and payment pages from your backend with the Script Monitoring REST API: base URL, API keys and scopes, rate limit, paging and errors.

Source: https://docs.scriptmonitoring.com/api/ · Plan: All plans · Updated 2026-10-13

The Script Monitoring REST API lets your backend create and delete teams, register and remove domains, and add payment pages, with an API key from **Developers > API keys**. It is a JSON API at `https://data.scriptmonitoring.com/v1/`, limited to 60 requests per minute per organization. The full OpenAPI document is at [data.scriptmonitoring.com/docs](https://data.scriptmonitoring.com/docs).

## How do I authenticate?

Send your API key as a Bearer token in the `Authorization` header:

```http
Authorization: Bearer sm_org_14829305716342_…
```

```shell
curl https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer $SCRIPT_MONITORING_API_KEY"
```

Create keys under **Developers > API keys**. A key is shown once, so store it in your secrets manager and use it only from your backend. The examples read it from `SCRIPT_MONITORING_API_KEY`.

| Key | Who can create it | What it can do |
| --- | --- | --- |
| Organization key, `sm_org_…` | Super admins | Any scope below, for every team in the organization. Pass `team_id` where an endpoint asks for it. |
| Team key, `sm_team_…` | Super admins and Admins of the team | The domain and payment page scopes, for its own team only. |

After the prefix comes a 14-digit key ID, then an underscore and the secret: `sm_team_10937462815530_…`. See [What does a key look like?](https://docs.scriptmonitoring.com/api-keys/#what-does-a-key-look-like).

> **Example IDs are not real** The IDs in these examples, such as team `14827391650423` and organization `org_11938475026617`, are reserved for documentation. They never belong to a live customer, and requests with them fail. Replace `YOUR_TEAM_ID` with your own team ID from the **Team ID** chip in the dashboard's top bar.

## Which key does each endpoint accept?

| Endpoint | Organization key | Team key |
| --- | --- | --- |
| [List teams](https://docs.scriptmonitoring.com/api/teams/list/) | Yes | No: `401` |
| [Create a team](https://docs.scriptmonitoring.com/api/teams/create/) | Yes, Pro and Enterprise | No: `401` |
| [Delete a team](https://docs.scriptmonitoring.com/api/teams/delete/) | Yes | No: `401` |
| [List domains](https://docs.scriptmonitoring.com/api/domains/list/) | Yes, any team in the organization | Yes, its own team. Another team's `team_id` gets `404 team_not_found`. |
| [Register domains](https://docs.scriptmonitoring.com/api/domains/create/) | Yes, with `team_id` | Yes, its own team |
| [Delete domains](https://docs.scriptmonitoring.com/api/domains/delete/) | Yes, with `team_id` | Yes, its own team |
| [Add a payment page](https://docs.scriptmonitoring.com/api/payment-pages/create/) | Yes, with `team_id` | Yes, its own team. Another team's `team_id` gets `401`. |

## What does a 401 mean?

Every endpoint answers `401` with the same body when the key can't be used:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

That covers a missing `Authorization` header, a mistyped or revoked key, a key whose prefix doesn't match its type (an organization key sent as `sm_team_…`, or the reverse), a key in a format created before `sm_org_` and `sm_team_` (those were revoked when the format changed), and a team key on the teams endpoints. A revoked key and one that never existed get the same answer. Create a new key under **Developers > API keys**.

A key carries only the scopes you pick when you create it:

| Scope | Label in the dashboard | Allows |
| --- | --- | --- |
| `teams:create` | Create teams | `POST /v1/teams` |
| `teams:delete` | Delete teams | `DELETE /v1/teams` |
| `teams:read` | List teams | `GET /v1/teams` |
| `domains:create` | Register domains | `POST /v1/domains` |
| `domains:delete` | Delete domains | `DELETE /v1/domains` |
| `domains:read` | List domains | `GET /v1/domains` |
| `payment_pages:create` | Add payment pages | `POST /v1/payment-pages` |

A create or delete scope also allows looking up a single record (`?name=` or `?domain=`); listing everything needs the read scope.

## What are the limits?

60 requests per minute per organization, shared by every key and endpoint. Over the limit the API answers `429` with `{"error":"rate_limited"}`.

## How does paging work?

List endpoints take `limit` (1 to 100, default 50) and `cursor`, and return `next_cursor`. Pass it back as `cursor` for the next page; it is `null` on the last page.

## What do errors look like?

Every error has the same body:

```json
{ "error": "insufficient_scope", "message": "..." }
```

| Status | Common `error` values |
| --- | --- |
| 400 | `invalid_request`, `invalid_cursor` |
| 401 | `unauthorized`: missing, invalid or revoked key, or a team key on a teams endpoint |
| 402 | `upgrade_required` |
| 403 | `insufficient_scope`, `organization_suspended`, `team_suspended` |
| 404 | `team_not_found` |
| 409 | `team_name_exists`, `team_subscription_attached` |
| 429 | `rate_limited` |
| 503 | `rate_limit_unavailable` and endpoint-specific `*_unavailable` errors: retry later |

## Frequently asked questions

### Which plans include the REST API?

Every plan. Creating teams with the API needs Pro or Enterprise; on Free, `POST /v1/teams` answers 402 `upgrade_required`.

### Is the dashboard's GraphQL API supported?

No. The GraphQL API is the dashboard's own and is not a public interface. API keys do not authenticate it.

### Do keys expire?

No. A key works until you revoke it under **Developers > API keys**. Revoking all of an organization's keys at once is also possible there.

### Why does my key get 401 unauthorized?

The key is missing, mistyped, revoked, or in a format that is no longer accepted. Only keys starting with `sm_org_` or `sm_team_` work; older keys were revoked when the format changed. A team key also gets 401 on the teams endpoints. Create a new key under **Developers > API keys**.

## Related

- [Register domains](https://docs.scriptmonitoring.com/api/domains/create/)
- [Webhooks](https://docs.scriptmonitoring.com/webhooks/)

---

# List teams

> GET /v1/teams lists the teams in your organization with their ID, name, creation date and suspension state. Needs an organization API key.

Source: https://docs.scriptmonitoring.com/api/teams/list/ · Plan: All plans · Updated 2026-10-13

`GET /v1/teams` lists the teams in your organization, page by page. Pass `name` to look up one team. Organization keys only (`sm_org_…`), with the `teams:read` scope; `teams:create` or `teams:delete` can look up a single `name`. A team key gets `401`.

```shell
curl "https://data.scriptmonitoring.com/v1/teams/?name=Payments" \
  -H "Authorization: Bearer sm_org_14829305716342_…"
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `teams:read` (or `teams:create` / `teams:delete` for a `name` lookup). |
| Team key (`sm_team_…`) | No: `401`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body, and so does a team key:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Query parameters

| Name | Description |
| --- | --- |
| `name` | Exact team name, 3 to 32 characters. |
| `limit` | Page size, 1 to 100 (default 50). |
| `cursor` | The `next_cursor` from the previous page. |

## Response

```json
{ "data": [{ "id": "14827391650423", "name": "Payments", "createdAt": "...", "suspended": false }], "next_cursor": null }
```

Errors: `400`, `401` (also for team keys), `403`, `429`, `503`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Create a team](https://docs.scriptmonitoring.com/api/teams/create/)

---

# Create a team

> POST /v1/teams creates a team in your organization and returns its ID. Needs an organization key with teams:create, on Pro or Enterprise.

Source: https://docs.scriptmonitoring.com/api/teams/create/ · Plan: Pro and Enterprise · Updated 2026-10-13

`POST /v1/teams` creates a team and returns its ID, ready for [Register domains](https://docs.scriptmonitoring.com/api/domains/create/). Organization keys only (`sm_org_…`), with the `teams:create` scope; a team key gets `401`. Creating teams with the API is included in Pro and Enterprise: on Free it answers `402 upgrade_required`.

```shell
curl -X POST https://data.scriptmonitoring.com/v1/teams/ \
  -H "Authorization: Bearer sm_org_14829305716342_…" \
  -H "Content-Type: application/json" \
  -d '{"name": "Payments"}'
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `teams:create`, on Pro and Enterprise. |
| Team key (`sm_team_…`) | No: `401`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body, and so does a team key:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Request body

| Field | Type | Description |
| --- | --- | --- |
| `name` | string | 3 to 32 characters, unique in the organization. |

## Response

`201` with:

```json
{ "data": { "teamId": "14827391650423" } }
```

On an Enterprise organization the new team is on Enterprise. On a Pro organization it starts on Free and needs its own subscription.

Errors: `400`, `401`, `402 upgrade_required`, `403` (`insufficient_scope`, `organization_suspended`), `409 team_name_exists` (the body includes the existing `teamId`), `429`, `503`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Register domains](https://docs.scriptmonitoring.com/api/domains/create/)

---

# Delete a team

> DELETE /v1/teams deletes a team and its domains by team ID. Needs an organization key with teams:delete; a team with a subscription can't be deleted.

Source: https://docs.scriptmonitoring.com/api/teams/delete/ · Plan: All plans · Updated 2026-10-13

`DELETE /v1/teams` deletes a team and its domains. Organization keys only (`sm_org_…`), with the `teams:delete` scope; a team key gets `401`. A team with a subscription attached is refused with `409 team_subscription_attached`.

```shell
curl -X DELETE https://data.scriptmonitoring.com/v1/teams/ \
  -H "Authorization: Bearer sm_org_14829305716342_…" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "YOUR_TEAM_ID"}'
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `teams:delete`. |
| Team key (`sm_team_…`) | No: `401`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body, and so does a team key:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Request body

| Field | Type | Description |
| --- | --- | --- |
| `team_id` | string | The team's ID (digits). |

## Response

```json
{ "data": { "status": "deleted", "teamId": "14827391650423", "deletedDomains": 2 } }
```

Errors: `400`, `401`, `403`, `404 team_not_found`, `409 team_subscription_attached`, `429`, `503 team_deletion_unavailable`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [List teams](https://docs.scriptmonitoring.com/api/teams/list/)

---

# List domains

> GET /v1/domains returns your registered domains with their team, Script tag or Agentic crawler mode, wildcard and suspension state, page by page.

Source: https://docs.scriptmonitoring.com/api/domains/list/ · Plan: All plans · Updated 2026-10-13

`GET /v1/domains` lists the domains registered in your organization, or in one team, with a cursor for paging. Pass `domain` to look up one hostname. Needs the `domains:read` scope; any `domains:*` scope can look up a single `domain`. Organization keys see every team; a team key sees its own team only.

With an organization key, for one team:

```shell
curl "https://data.scriptmonitoring.com/v1/domains/?team_id=YOUR_TEAM_ID&limit=50" \
  -H "Authorization: Bearer sm_org_14829305716342_…"
```

With a team key, which always reads its own team:

```shell
curl "https://data.scriptmonitoring.com/v1/domains/?limit=50" \
  -H "Authorization: Bearer sm_team_10937462815530_…"
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes: every team in the organization, or one with `team_id`. |
| Team key (`sm_team_…`) | Yes: its own team only. A `team_id` for any other team gets `404 team_not_found`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Query parameters

| Name | Description |
| --- | --- |
| `team_id` | Restrict to one team. It must belong to the key's organization; with a team key, it can only be the key's own team. |
| `domain` | Exact hostname to look up. |
| `limit` | Page size, 1 to 100 (default 50). |
| `cursor` | The `next_cursor` from the previous page. |

## Response

```json
{
  "data": [
    {
      "id": "...",
      "domain": "shop.example.com",
      "teamId": "14827391650423",
      "managed": true,
      "wildcard": false,
      "suspended": false,
      "createdAt": "..."
    }
  ],
  "next_cursor": null
}
```

`managed` is `true` for a Script tag domain and `false` for an Agentic crawler domain. Errors: `400`, `401`, `403`, `404 team_not_found`, `429`, `503`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Register domains](https://docs.scriptmonitoring.com/api/domains/create/)

---

# Register domains

> POST /v1/domains registers up to 100 domains in a team in one call and reports, per domain, whether it was created, already existed or was invalid.

Source: https://docs.scriptmonitoring.com/api/domains/create/ · Plan: All plans · Updated 2026-10-13

`POST /v1/domains` registers 1 to 100 domains in a team. Each domain gets its own result, so one invalid hostname does not fail the others. Needs the `domains:create` scope. Organization keys must pass `team_id`; a team key always acts on its own team.

With an organization key:

```shell
curl -X POST https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer sm_org_14829305716342_…" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "YOUR_TEAM_ID", "domains": ["shop.example.com", "checkout.example.com"]}'
```

With a team key, no `team_id`:

```shell
curl -X POST https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer sm_team_10937462815530_…" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["shop.example.com", "checkout.example.com"]}'
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `domains:create` and a `team_id` in the body. |
| Team key (`sm_team_…`) | Yes, with `domains:create`, on its own team. It doesn't need `team_id`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Request body

| Field | Type | Description |
| --- | --- | --- |
| `domains` | string[] | 1 to 100 hostnames. |
| `team_id` | string | The team's ID (digits). Required with an organization key. |

## Response

```json
{
  "data": {
    "results": [
      { "status": "created", "input": "shop.example.com", "domain": "shop.example.com", "domainId": "..." },
      { "status": "invalid", "input": "localhost", "code": "internal_domain", "message": "..." }
    ],
    "totals": { "created": 1, "existing": 0, "invalid": 1 }
  }
}
```

`status` is `created`, `existing` or `invalid`. An invalid result carries a `code`: `empty_domain`, `invalid_domain`, `public_suffix_domain`, `internal_domain`, `reserved_ip`, `wildcard_conflict`, `subdomain_conflict`, `domain_already_licensed` or `internal_error`.

Errors: `400`, `401`, `403` (`insufficient_scope`, `team_suspended`), `404 team_not_found`, `429`, and `503 domain_registration_unavailable` when the domains were saved but not yet synchronized: retry the same call.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Delete domains](https://docs.scriptmonitoring.com/api/domains/delete/)

---

# Delete domains

> DELETE /v1/domains removes up to 100 domains from a team by domain ID and reports, per ID, whether it was deleted or not found.

Source: https://docs.scriptmonitoring.com/api/domains/delete/ · Plan: All plans · Updated 2026-10-13

`DELETE /v1/domains` removes 1 to 100 domains from a team. It takes domain IDs, not hostnames: get them from [List domains](https://docs.scriptmonitoring.com/api/domains/list/). Needs the `domains:delete` scope. Organization keys must pass `team_id`; a team key always acts on its own team.

With an organization key:

```shell
curl -X DELETE https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer sm_org_14829305716342_…" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "YOUR_TEAM_ID", "domains": ["456"]}'
```

With a team key, no `team_id`:

```shell
curl -X DELETE https://data.scriptmonitoring.com/v1/domains/ \
  -H "Authorization: Bearer sm_team_10937462815530_…" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["456"]}'
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `domains:delete` and a `team_id` in the body. |
| Team key (`sm_team_…`) | Yes, with `domains:delete`, on its own team. It doesn't need `team_id`. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Request body

| Field | Type | Description |
| --- | --- | --- |
| `domains` | string[] | 1 to 100 domain IDs (digits). |
| `team_id` | string | The team's ID. Required with an organization key. |

## Response

```json
{
  "data": {
    "results": [{ "status": "deleted", "domainId": "456", "domain": "shop.example.com" }],
    "totals": { "deleted": 1, "not_found": 0 }
  }
}
```

`status` is `deleted` or `not_found`. Errors: `400`, `401`, `403`, `404 team_not_found`, `429`, `503 domain_deletion_unavailable`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [List domains](https://docs.scriptmonitoring.com/api/domains/list/)

---

# Add a payment page

> POST /v1/payment-pages adds one payment page selector to a team, the same selectors you manage in Setup step 4, and says whether it was new.

Source: https://docs.scriptmonitoring.com/api/payment-pages/create/ · Plan: All plans · Updated 2026-10-13

`POST /v1/payment-pages` adds one payment page selector to a team: the same list you edit in Setup step 4 (see [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)). Needs the `payment_pages:create` scope. Organization keys must pass `team_id`; a team key acts on its own team.

With an organization key:

```shell
curl -X POST https://data.scriptmonitoring.com/v1/payment-pages/ \
  -H "Authorization: Bearer sm_org_14829305716342_…" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "YOUR_TEAM_ID", "payment_page": "shop.example.com/checkout"}'
```

With a team key, no `team_id`:

```shell
curl -X POST https://data.scriptmonitoring.com/v1/payment-pages/ \
  -H "Authorization: Bearer sm_team_10937462815530_…" \
  -H "Content-Type: application/json" \
  -d '{"payment_page": "shop.example.com/checkout"}'
```

## Which keys work?

| Key | Accepted |
| --- | --- |
| Organization key (`sm_org_…`) | Yes, with `payment_pages:create` and a `team_id` in the body. |
| Team key (`sm_team_…`) | Yes, with `payment_pages:create`, on its own team. `team_id` is optional; if you pass it, it must be the key's own team. |

A missing, mistyped or revoked key, a key whose prefix doesn't match its type, or a key created before the `sm_org_` / `sm_team_` format gets `401` with this body, and so does a team key whose `team_id` names another team:

```json
{ "error": "unauthorized", "message": "Missing or invalid bearer token." }
```

## Request body

| Field | Type | Description |
| --- | --- | --- |
| `payment_page` | string | A selector as host and path, without `https://` and without spaces. |
| `team_id` | string | The team's ID. Required with an organization key; with a team key, optional and only its own team. |

## Response

```json
{ "data": { "status": "created", "teamId": "14827391650423", "paymentPage": "shop.example.com/checkout" } }
```

`status` is `created` or `existing`. Errors: `400` (`invalid_request`, `invalid_payment_page`), `401`, `403`, `404 team_not_found`, `429`, `503 payment_page_unavailable`.

## Related

- [REST API](https://docs.scriptmonitoring.com/api/)
- [Payment pages](https://docs.scriptmonitoring.com/payment-pages/)

---

# Webhooks

> Receive Script Monitoring alerts on your own URL. Verify the x-scriptmonitoring-signature HMAC-SHA256 header and read the alert.created JSON payload.

Source: https://docs.scriptmonitoring.com/webhooks/ · Plan: Pro and Enterprise · Updated 2026-10-13

A webhook destination posts each Script Monitoring alert to a URL you own, as JSON (or as a ready-made Slack or Discord message). You add it to a notification rule under **Settings > Notifications**, and every request is signed so you can check it really came from Script Monitoring. Webhook destinations are on Pro and Enterprise.

## How do I add a webhook?

In **Settings > Notifications**, open a rule (or **New rule**), click **Webhook** under **Where to**, and fill in **URL**, **Signing secret** and **Format** (**JSON**, **Slack** or **Discord**). See [Notifications](https://docs.scriptmonitoring.com/notifications/) for the rest of the rule.

![Where a rule sends: email to all team members or named recipients, a webhook (JSON, Slack or Discord), or an S3 bucket.](https://docs.scriptmonitoring.com/screenshots/notification-destination-sheet-light.webp)

## How do I verify the signature?

Script Monitoring sends a `POST` with a JSON body to your URL, and retries up to two times. Every request has an `x-scriptmonitoring-signature` header: the HMAC-SHA256 of the raw body, keyed with your **Signing secret**, as uppercase hex. Verify it before trusting the payload. In Node.js:

```js

function isFromScriptMonitoring(rawBody, signature, secret) {
  const expected = createHmac("sha256", secret).update(rawBody).digest("hex").toUpperCase();
  return signature?.length === expected.length && timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}
```

## What does an alert look like?

With the **JSON** format, an alert (`alert.created`) looks like this:

```json
{
  "event": "alert.created",
  "timestamp": "...",
  "domain_id": "...",
  "domain": "shop.example.com",
  "trigger_type": "...",
  "data": {
    "target_type": "...",
    "target": "...",
    "action": "...",
    "ruleset_id": "...",
    "ruleset_name": "...",
    "ruleset_description": "...",
    "script_urls": ["..."]
  },
  "destination_id": "..."
}
```

Vulnerability alerts add `vuln_cve_id`, `vuln_package`, `vuln_severity` and `vuln_reference_url` to `data`. The **Slack** and **Discord** formats send a ready-made message for that app instead. Scheduled digests and the PCI evidence pack notice are always sent as JSON.

## What does a security header change look like?

The **Security headers changed** rule sends `security_headers.changed` when a security header changes on a payment page:

```json
{
  "event": "security_headers.changed",
  "sent_at": "...",
  "team_id": "...",
  "data": {
    "domain_id": "...",
    "domain": "shop.example.com",
    "checkout_paths": ["..."],
    "changes": [
      { "header_name": "content-security-policy", "from_value": "...", "to_value": "...", "from_date": "...", "to_date": "..." }
    ]
  }
}
```

## Frequently asked questions

### Can I send alerts to Slack or Discord?

Yes. Set the destination's **Format** to **Slack** or **Discord** and use the channel's incoming webhook URL. Scheduled digests and the PCI evidence pack notice are always sent as JSON.

### What if my endpoint is down?

Script Monitoring retries a failed request up to two times. A rule's **Last delivery** column shows its latest webhook or S3 delivery.

### How do I tell a test from a real alert?

A test adds "This is a test run. No action is required." to the description.

## Related

- [Notifications](https://docs.scriptmonitoring.com/notifications/)