Keys and the dashboard

Running Kaidn day to day: issuing and revoking keys, which key goes where, and what the dashboard does that the API does not.

Creating and revoking keys

Every request authenticates with an x-api-key header. Create as many keys as you like, one per integration or environment, from the API keys page in your dashboard.

Shown once. The raw key appears only at creation, we store just a hash. Lost it? Create a new one.
Named & monitored. Each key has a name, a prefix (e.g. kdn_live_ab…), and a last-used time.
Revoke instantly. A revoked key is rejected on its very next request, no propagation delay.
Scoped to the API. Keys reach the scoring & data endpoints only; account and key management stay session-only in the dashboard.

Two kinds of key, and the one that goes in a web page

This is the distinction worth getting right on day one, because the two keys look similar and only one of them is safe in front of a user.

	Secret key	Publishable tracker key
Looks like	`kdn_live_ab…`	`pk_live_…`
Lives in	your server, an environment variable	your page source, in a script tag
Can	score events, run lookups, read your data, edit rules and lists	send device information, and nothing else
Cannot	be exposed to a browser, ever	read anything, score anything, or be used from a domain you did not authorise
If it leaks	revoke it immediately, it is your account	little to gain: it is domain-locked and write-only

The publishable key is meant to be visible. It is locked to the domains you set on the tracker, so a copied key cannot be used from another site, and it can only ever send fingerprints. That is why it can sit in page source while your secret key never can.

Installing the browser tracker

Optional, and it is what makes device recognition possible. Without it Kaidn still scores the IP, the email and the phone; with it you also get the device signals and the connection fingerprint.

In the dashboard, Fraud Scoring API → Device trackers, create a tracker and list the domains it may run on. You get a publishable key.
Drop its script tag on the page and call Kaidn.trigger('#your-form'). On submit it appends a hidden kaidn_device_id field before your form posts.
Your backend reads that field and passes it to /v1/score as device_id. The verdict comes back to your server, never to the browser.

It fails open, on purpose. If the script is blocked or errors, your form still submits and your signup still works. A fraud tool that can take down your signup page is a worse problem than the fraud.

On a logged-in page, Kaidn.watch() re-checks the same device every minute or so, which is how a connection that changes mid-session becomes visible. Full API and the concepts behind it are in core concepts.

<!-- Create a tracker in the dashboard (Fraud Scoring API → Device trackers)
     to get your publishable key + this exact snippet, locked to your domains. -->
<script src="https://api.kaidn.io/fp/pk_live_YOUR_KEY.js" defer></script>
<script>
  // The tag above is deferred, so it runs AFTER the page is parsed. This inline
  // block would otherwise run first and hit "Kaidn is not defined".
  document.addEventListener('DOMContentLoaded', function () {
    // Bind your form: on submit, Kaidn fingerprints the device, beacons the
    // JA4 to our edge, appends a hidden "kaidn_device_id" field, THEN submits.
    // Your backend receives device_id automatically, no manual wiring.
    Kaidn.store('user_id', window.CURRENT_USER_ID);  // optional: attach your IDs
    Kaidn.trigger('#signup-form');
    Kaidn.init();

    // Optional: on logged-in / session pages, start a heartbeat so Kaidn sees the
    // connection over time and catches a VPN drop (real IP leaking) mid-session.
    var watch = Kaidn.watch();     // re-beacons the same device_id every ~60s
    // ...later, on logout / route change:  watch.stop();
  });
</script>

Metering: collection is free and rate-limited. You are billed per scored decision, so fingerprinting is never a separate line item.

Reading the dashboard

Everything the API returns is also a screen, for the people on your team who will not be making HTTP requests.

screen	what it answers
Overview	what has been happening, and how the verdict mix is moving
Events	every scored event, newest first, filterable by verdict and event name
One event	why this specific decision was made: the checks that fired, their weights, the raw evidence
Review queue	what is waiting on a person, worst first
Rules	the weights and thresholds, editable
Lists	your allowlist and blocklist
Trackers	publishable keys and their authorised domains
Billing	usage against your plan

The single-event screen is the one that matters most in an argument. When a customer says they were treated unfairly, it is the page that shows exactly what was found, so you can answer them with a fact instead of a score.

Rules and lists without touching the API

Weights, thresholds, allowlists and blocklists are all editable in the dashboard, and the change takes effect on the next request. A fraud analyst can tune the engine without waiting for an engineer, which is the point.

The same capability is in the API as /v1/config and /v1/lists if you would rather keep your configuration in version control.

Two things are deliberately dashboard-only. Editing configuration and GDPR erasure are not exposed to the MCP server in any mode. Both are decisions a person should see before making, not something an agent should be able to do in a loop.

Billing and limits

An event is one call to /v1/score. The free-tool checkers and dashboard views do not count against your allowance.
Fingerprint collection is not metered. The beacon is free; you pay for decisions.
240 requests a minute per key, with standard rate-limit headers and a 429 above it.
Going over your monthly plan does not silently stop scoring. Depending on the plan we throttle, queue the overage for billing at the published rate, or ask you to upgrade.

Plans and prices are on the pricing page.

PreviousGuidesWorking code for the common jobs NextGlossaryEvery term defined