Skip to main content
A site is one website under your account: a name, the origins it is allowed to run on, a site id, and a signed token the SDK presents on every connection. You create it once, put one script tag on the pages, and the site reports back when the first visit arrives.

​
Create the site

In the console, add a website with its name and its address. Through the API:
The answer carries the site’s _id (the site id that goes in the script tag), name, host, enabled, urls (the allowed origins as stored), state (deployed, connected), vertical, shadow, card_enabled and holdout_pct. The name is cut at 50 characters. See Sites: create.

​
Allowed origins

The origins are the only places the SDK will run. They are signed into the site’s token, and the settings call, the cart beacon, the card routes and the collector’s handshake all check the page’s Origin against them. The rules, applied on create and on every change:
  • https only. http://acme.com is rewritten to https://acme.com; the SDK only ever loads over https.
  • One registrable root per site. www.acme.com and acme.com and shop.acme.com belong together. acme.com and acme-outlet.com do not; the second company’s domain goes on its own site. This is what stops one token from working across two unrelated businesses.
  • The www and apex siblings are added for you, and when the site can be reached, the origin it lands on after redirects is added too. This heads off the most common install failure: the owner types acme.com, the site redirects to https://www.acme.com, and the SDK is refused on a page where the tag is sitting correctly.
  • Staging hosts go on the list like any other origin, as long as they share the root.
Change the list with PATCH /v1/sdk/{id} and allowed_origins. The token is re-signed and the change takes effect within a minute; the SDK picks up the new token on the next page load.

​
The script tag

In the <head> of every page. The tag never changes: the bundle is served with long cache headers and the page learns about a new version from the settings response. Single-page apps need nothing extra; the SDK follows history changes. The full contract (the settings call, the visitor frame, the signals) is in Install the SDK.

​
Deployed and connected

The site record carries two flags, and the console shows them as the install status:
  • deployed is set when the install check finds the tag on your page. The tag is on the page.
  • connected is set when a visitor’s browser opens the collector connection with the site’s token. Signals are arriving. It is written once, on the first connection, so a site that has been live for a day is not updated per visit.
If deployed is set and connected is not, the tag is on the page but no browser has connected: either nobody has visited since the tag went in, or the connection was refused because the page’s origin is not on the list. Compare the page’s origin with urls on the site record. Two checks you can run from your side:
  • GET /v1/sdk/{id}/install-check fetches your page from NextIntent’s side and reports whether the tag is present. It follows redirects and refuses private addresses.
  • GET /v1/resolve-check?host= says whether a hostname resolves, which the add-website form uses while you type.

​
What a site is worth

One script tag is the whole install. There is nothing to configure per page, no events to wire up, and no cookie on your domain. Everything after the tag is a setting on the site record or a line on the facts sheet, so the site can go from watching to speaking without touching the pages again.