Skip to main content
A domain is a site you protect with ShieldLabs. Your account holds one or more domains. Each domain gets its own key set and its own webhook endpoints (up to 10), and all of them draw on your account’s included identifications. A key set issued for one domain works only on that domain, and on its subdomains while the domain accepts them. If you run a single site, you have one domain. If you run several sites (or staging and production), each is a separate domain with its own configuration.

​
Add a domain

Add domains in the analytics dashboard under Integration > Domains. Integration describes the screen.
1

Open Integration

Go to the analytics dashboard and open Integration > Domains.
2

Add the domain

Enter the hostname you want to protect, for example myshop.com, without https:// or a path. Subdomains such as app.myshop.com are accepted by default; you can switch that off for the domain. Adding it provisions the domain’s Public Key, Private API Key and Secret Key.
3

Install the snippet

Drop the snippet onto that domain with its Public Key in the URL, following Install the snippet for the full client setup. On pages where users are signed in, call checkAuthenticatedUser with a hashed User HID instead, as Identify signed-in users shows.
4

Register webhook endpoints

Add one or more webhook endpoints for the domain under Integration > Webhooks, so each identification’s Risk Score reaches your server. See Webhooks for registration, verification, and testing.
Adding a domain mints a fresh key set on the spot. Store the Secret Key and the Private API Key server-side, in environment variables or a secrets manager.

​
What every domain carries

Integration > Domains in the analytics dashboard: example.com Reporting with 11,020 identifications in the last 7 days and subdomains Accepted, dev.example.com Reporting with 1,460 and Exact host, shop.example.com Paused with 0 and Exact host, and Upgrade plan to add a domain.Integration > Domains in the analytics dashboard in the dark theme: example.com Reporting with 11,020 identifications in the last 7 days and subdomains Accepted, dev.example.com Reporting with 1,460 and Exact host, shop.example.com Paused with 0 and Exact host, and Upgrade plan to add a domain.

Integration > Domains in the analytics dashboard: each domain's status and subdomain setting.

You can read the live configuration for a domain at any time with the Profile endpoint. It returns both keys masked (see API keys), so you can confirm a domain without exposing its credentials:
The Profile call is free: it never counts against your plan. Use it as a quick health check that a domain is enabled.

​
Verification is automatic

You do not add a DNS record or upload a file to verify a domain. Verification happens on its own once live snippet traffic is seen.
1

Install the snippet with the domain's Public Key

The Public Key works on the domain it was issued for, and on its subdomains while the domain accepts them. ShieldLabs resolves the domain from the request Origin, then Referer, then Host, and checks it against the Public Key.
2

Trigger one identification

Load a page that runs the snippet. The first identification that arrives for that domain verifies it.
3

Confirm in the analytics dashboard

Under Integration > Domains, the domain’s status changes from Pending to Reporting once that first identification is recorded.
If a Public Key is served from a host it was not issued for, the identification call is rejected with 401, and the domain stays unverified. A key lifted from your page source works only on the domain it was issued for and, while that domain accepts them, its subdomains.

​
Subdomains and host matching

ShieldLabs resolves the host of each call from the request Origin, then Referer, then Host, and strips a leading www., so www.myshop.com and myshop.com are the same domain. A registered host that matches exactly always wins. Otherwise, while a domain accepts subdomains (the default for every new domain), calls from its subdomains, such as app.myshop.com or checkout.myshop.com, are accepted with that domain’s Public Key and reported under it.
To keep a subdomain apart, with its own key set, webhook endpoints and figures in the analytics dashboard, add it as its own domain: the exact match takes precedence over the parent. Switch off subdomain traffic on the parent when only the exact host should be accepted. Each added domain uses one of your plan’s domain slots.

​
How many domains you can add

Your plan sets how many active domains one account can hold. Adding one past the cap returns an error naming the plan and its limit, for example starter plan allows at most 1 domain. Deleting a domain frees its slot, and moving to a higher plan raises the cap right away. If you are already above the cap after a plan change, the domains you have keep running; only new ones are refused. Each active domain also shares one ingest budget across every visitor IP on that host (Free and Starter 5 requests/second, Growth 10, Scale 15). Crossing it returns 429 without banning the domain. After ten saturated seconds in a row the domain shows as Frozen in the analytics dashboard: calls get 429, are not billed, and processing resumes on its own. The full gateway table is on Rate limits.

​
What is per domain and what is shared

Each domain has its own credentials, webhooks and status. Your account’s included identifications are shared by all of them.

Separate credentials

Each domain has its own Public Key, Private API Key and Secret Key. A key set issued for one domain authenticates only that domain. Rotating one domain’s keys never touches another’s.

Separate webhooks

Each domain can register up to 10 webhook endpoints. Point them at the same handler or different handlers, as you prefer.

One shared quota

All domains draw on your account’s included identifications, tracked for the billing cycle on the Usage screen. Pick All domains or one domain in the analytics dashboard to see its identifications.

Independent status

Pausing one domain stops its identification calls and Server API access without affecting the others.

​
Next steps

With the domain added, wire its Public Key into the snippet and identify signed-in users with checkAuthenticatedUser, keep its Secret Key and Private API Key on your server, and register webhook endpoints that verify X-Shield-Signature per the webhooks guide.