Bot & Automation

Is this a human, a hostile script, or a trusted automated agent? Bot & automation detection classifies the session, surfaces the individual automation and abuse signals behind the verdict, and lets a well-behaved bot prove who it is. All of it lands in the risk snapshot.

Bot detection is an evidence provider. It labels the traffic and shows its reasoning — it never blocks. A verified_bot may be exactly the partner crawler you want to allow; a hostile script is yours to stop. You decide.

How it works

Every analysed session is classified (botClassification) with a botConfidence, backed by the discrete signals that fired (botSignals) — headless-browser hints, synthetic input cadence, scripted checkout, and abuse patterns such as credential stuffing, trial abuse and signup abuse. A client may declare itself as an automated agent (botTrustDeclared); if it is a registered, verified bot, the snapshot binds it to its issuer and reports a trust outcome and tier.

Request

Bot signals come back in the standard analyze/analyze-sync snapshot — no separate call. Streaming interaction events sharpens the automation verdict.

<script src="https://cdn.lunixi.com/lunixi-identity.min.js"></script>
<script>
  const client = await Lunixi.identity.init({
    sessionBootstrapUrl: '/lunixi/identity/bootstrap',
    subjectId: 'cus_8f2a9c',
    productContext: 'login',
  });
 
  // Stream interaction events, then analyse.
  await client.trackBatch(events);
  const snapshot = await client.analyze();
  // snapshot.botClassification, snapshot.botConfidence,
  // snapshot.botSignals, snapshot.botTrustOutcome ...
</script>

Snapshot

The bot portion of the snapshot:

{
  "botClassification": "automation_likely",
  "botConfidence": 0.70,
  "botSignals": ["headless_hints", "input_cadence_synthetic", "credential_stuffing_pattern"],
  "botTrustOutcome": "unverified",
  "botTrustTier": null,
  "botTrustDeclared": false,
  "botIssuerId": null,
  "botKeyId": null,
  "botActorId": null
}

A verified partner crawler that registered its issuer and key instead comes back trusted:

{
  "botClassification": "verified_bot",
  "botConfidence": 0.99,
  "botTrustOutcome": "verified",
  "botTrustTier": "partner",
  "botTrustDeclared": true,
  "botIssuerId": "iss_partner_crawler",
  "botKeyId": "key_2026a"
}

Signals

Field	What it tells you
`botClassification`	Bot verdict — human, automation_likely, verified_bot, …
`botConfidence`	Confidence in the classification (0–1)
`botSignals`	The individual automation/abuse signals observed
`botTrustOutcome`	Outcome of declared/verified-bot evaluation (e.g. verified, unverified)
`botTrustTier`	Trust tier assigned to a recognised bot
`botTrustDeclared`	The client declared itself as an automated agent
`botIssuerId`	The registered issuer of a verified bot
`botKeyId`	The registered key that signed the declaration
`botActorId`	The verified bot's actor identifier

Abuse patterns — credential stuffing, trial abuse, signup abuse — appear within botSignals and the finding surface rather than as separate top-level fields.

Notes

Automation and abuse detection are default-on — headless hints, synthetic cadence and abuse patterns are live the moment the SDK runs, with no configuration.
Declared-bot binding is default-on — a client that declares itself is recorded (botTrustDeclared), and evaluated for trust.

Verified-bot allow-listing is configurable. To have a partner's automated traffic returned as verified_bot, you register the bot's issuer and key for your account; declarations signed by that key then bind to botIssuerId/botKeyId and report a trust tier. Until an issuer is registered, a declared bot is reported as unverified — declaration alone is never treated as trust.

Next steps

The Risk Snapshot — the full field reference
Device & Continuity — behavioral biometrics: human vs scripted
Network Intelligence — automation over hosting and proxy networks
Server-side API — querying analysed sessions

Network Intelligence Mobile Threat