Seentics

Integration

API keys

One key per integration, scoped to the data it needs and to a single website.

Creating a key

  • Open Developers → API keys on the website you want to read.
  • Give the key a name that says where it will be used — you will thank yourself later.
  • Tick the scopes it needs, and only those.

The secret is shown once

Only a hash is stored, so the full key cannot be shown again. Copy it when it appears; if you lose it, delete the key and mint another.

What a key looks like

text
snt_a1b2c3_K7pQ...

The middle segment is a slice of the website ID, so a leaked key is traceable to a site without a database lookup. The random half is 32 bytes of base64url. The dashboard lists keys by their first 16 characters — that prefix is all it keeps in plain text.

If you saw snt_live_ or snt_age_ in older docs

Those prefixes were never real. Keys have always been snt_ plus a site slice.

Using a key

Send it as an X-API-Key header. Never as a query parameter — URLs end up in server logs, browser history and referrer headers.

bash
curl -H "X-API-Key: $SEENTICS_API_KEY" \
  "https://app.seentics.com/api/v1/raw/v1/catalogue"
report.js
const res = await fetch(
  'https://app.seentics.com/api/v1/raw/v1/catalogue',
  { headers: { 'X-API-Key': process.env.SEENTICS_API_KEY } },
);

Scopes

A key carries a set of scopes, and each endpoint requires one. A key built for traffic reporting cannot read session replays — that separation is the point of having scopes at all.

The scope vocabulary is published by the server, so the current list is always the one in the dashboard when you create a key. The API reference in Developers → API reference shows the required scope beside every endpoint.

GET/api/v1/websites/scopes
Every scope the server accepts, with a description. Requires a key.

Why the list is not printed here

It used to be, and four of the scopes named did not exist. A list in prose has no way to stay in step with the server; the dashboard reads it live.

Keeping keys safe

  • Keep keys server-side. A key in browser JavaScript is a public key — anyone can read it from the network tab.
  • One key per integration, so you can revoke one without breaking the others.
  • Scope narrowly. A reporting job does not need replay access.
  • Keys are per website. A key for one site cannot read another, even under the same account.
  • The dashboard shows each key's last-used time — a key that has not been used in months is a key to delete.

See the REST API page for base URLs and error codes.

PreviousREST APINextUI blocks