MCPInstall

sumsub-integrate-dint-websdk

by sumsubAI & Agents

Add Sumsub Device Intelligence (the Fisherman module) to a web project that already verifies users with the Sumsub WebSDK. TRIGGER when the user asks to "add device intelligence", "enable device capture / fingerprinting in the WebSDK", "turn on Fisherman", "detect device fraud / multi-accounting in the verification flow", or asks how device risk labels get onto an applicant verified through the WebSDK. Covers the whole loop — enabling Capture device data on the level, the automatic in-SDK Fisherman lifecycle, the advanced self-rendered wiring, reading device signals (Devices tab, Device Check, risk labels, webhooks), sandbox testing, go-live checklist. SKIP for device intelligence on pages with NO WebSDK widget (login / signup / checkout) — use sumsub-integrate-dint-standalone; SKIP for the base WebSDK embed itself — use sumsub-integrate-websdk.

Installs
981
Last 24h
+16
Trending rank
#6788
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/sumsub/agent-skills --skill sumsub-integrate-dint-websdk
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads sumsub-integrate-dint-websdk automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Sumsub — Device Intelligence via the WebSDK

Add Device Intelligence (DI) to a project that already embeds the Sumsub WebSDK. DI is the fraud-detection layer that captures low-level device/browser signals (device fingerprint, bot/automation, VPN/proxy, emulator, incognito, reused-device) and attaches them to the applicant as device risk labels that feed risk scoring.

The JS module that does the capture is called Fisherman (npm @sumsub/fisherman) — same thing, different name. Inside the WebSDK you almost never touch it directly; the SDK ships and drives it for you.

⚠️ Sandbox tokens only

Do not accept or use a production App Token / secret during integration work. Insist on a sandbox pair from https://cockpit.sumsub.com/checkus/home?sbx=true — Connect Sumsub to your AI agent -> Build & configure -> Generate token. Token + secret are revealed once at creation; copy both before closing the dialog. Helper scripts in sibling skills enforce this with an sbx: prefix check; the curl recipes here assume the same. Deeper auth mechanics: sumsub-api-auth.

The lifecycle in one picture

 ┌───────────────────────────────┐  ← one-time, in the dashboard
 │ 1. "Capture device data" on    │     (verification level settings)
 │    on the verification level   │
 └───────────────┬───────────────┘
                 │
 ┌───────────────▼───────────────┐  ← your existing sumsub-integrate-websdk
 │ 2. WebSDK launches as usual    │     code. NOTHING new on the frontend.
 │    (same access token)         │
 └───────────────┬───────────────┘
                 │ the SDK auto-inits Fisherman with that token,
                 │ fingerprints the device, attaches it to the applicant
 ┌───────────────▼───────────────┐  ┌─────────────────────────────────┐
 │ 3. Sumsub computes device      │─▶│ Device risk labels on the       │
 │    signals + risk labels       │  │ applicant; feed risk scoring    │
 └───────────────┬───────────────┘  └─────────────────────────────────┘
                 │
 ┌───────────────▼───────────────┐  ← server reads the applicant /
 │ 4. You read the verdict +      │     receives the webhook (same as
 │    device signals server-side  │     the base WebSDK flow)
 └────────────────────────────────┘

The headline: for a standard WebSDK integration, DI is a dashboard toggle, not new code. Stages 3–4 below are the advanced (self-rendered) path and the result-reading details.

Stage 1 — Enable device capture on the level

DI rides along automatically in WebSDK 2.0 and the Mobile SDKs only when "Capture device data" is enabled in the verification level settings. In the dashboard: open the level → Device intelligence section → tick Capture device data. If you don't see the setting, DI isn't provisioned for the workspace — contact Sumsub to enable the product before continuing.

Optional BYOK: you can supply your own Fingerprint Pro credentials (public + secret API key) under DevSpace → Integrations → Fingerprint so devices are captured under your Fingerprint account. Without BYOK, Sumsub's own credentials are used — both work; BYOK only matters if you already run Fingerprint Pro.

That's the entire required setup. Re-launch your existing WebSDK flow and devices start getting captured.

Stage 2 — The automatic in-SDK lifecycle (no code)

With "Capture device data" on, the WebSDK, using the same access token your sumsub-integrate-websdk token endpoint already mints:

  1. Initializes Fisherman against the SDK's API host once the SDK config loads.
  2. Fingerprints the device on each step transition, binding it to the current (applicantId, attemptId).
  3. Re-initializes on a level transition (the attemptId changes), so a multi-level flow gets a fresh device binding per level.
  4. Forwards the resulting device id to the backend on subsequent calls so the capture is tied to the applicant.

You do not write, configure, or call any of this. It is listed so you can recognise it in logs / network traffic (/di/info, an /bhv/... events POST, an X-External-Device-Fingerprint request header).

Stage 3 — Advanced: self-rendered / headless wiring

Only relevant if you do not use the prebuilt snsWebSdk widget and drive the verification API yourself. Then you own the Fisherman lifecycle. Mirror the SDK's own behaviour — see examples/fisherman-self-render.ts:

// Shape only — the full impl (single-active-session class, attemptId re-init,
// try/catch fail-open, header forwarding) is in examples/fisherman-self-render.ts.
import { init, destroy, type Fisherman } from '@sumsub/fisherman'

let fisherman: Fisherman | undefined // module-level singleton

// init once with the SDK access token + region API host
fisherman = await init({ token, baseUrl, onError: () => { destroy() /* re-init after token refresh */ } })

// on each step transition — gate, then fingerprint bound to (applicantId, attemptId)
if (fisherman?.isDeviceIntelligenceEnabled) {
  const { visitorId } = await fisherman.fingerprint({
    linkedId: applicantId,
    deviceBindingId: `${applicantId}-${attemptId}`, // MUST change per level
  })
  // forward visitorId as the X-External-Device-Fingerprint header on the API calls that follow
}

Key rules the SDK follows and you must too:

  • Two-layer gate. The SDK gates init() itself on the config-level flag config.deviceIntelligenceSettings.enabled — when DI is off for the level it never calls init(). Then it gates each fingerprint() on the runtime flag fisherman.isDeviceIntelligenceEnabled (from /di/info). Mirror both: skip init when the config flag is false, never fingerprint unless the runtime flag is true (it errors / wastes a call).
  • On a level transition (attemptId changes) destroy() then init() again before the next fingerprint(), so devices bind to the right level.
  • Forward the returned visitorId as the X-External-Device-Fingerprint header on the verification API calls that follow the capture. (This header is device/stats enrichment — the actual applicant binding is the per-attempt deviceBindingId (applicantId-attemptId) above, not the header.)

Stage 4 — Read the device signals

DI does not change how you read the verdict — it enriches it. Keep the server-as-source-of-truth rule from the base WebSDK skill (webhook + authenticated applicant GET), and read the device data alongside it.

In the dashboard:

  • Applicant profile → Devices tab — every device seen, with risk labels.
  • Completed verification → Device Check block.
  • Transactions → a device row → View device details.

Via API / webhooks: the device risk labels land on the applicant, not in the webhook payload. The applicantReviewed webhook carries the verdict only (reviewResult) — treat it as the trigger to read the applicant server-side (same App-Token + HMAC auth as the base skill), here keyed by your externalUserId:

USER_ID="<your-externalUserId>"   # for a Sumsub applicant id instead: /resources/applicants/<applicantId>/one
PATH_Q="/resources/applicants/-;externalUserId=${USER_ID}/one"
TS=$(date -u +%s)
SIG=$(printf '%s%s%s' "$TS" "GET" "$PATH_Q" \
      | openssl dgst -sha256 -hmac "$SUMSUB_SECRET_KEY" -hex | awk '{print $NF}')
curl -sS --fail-with-body -H "X-App-Token: $SUMSUB_APP_TOKEN" -H "X-App-Access-Ts: $TS" \
     -H "X-App-Access-Sig: $SIG" -H "X-Agent-Source: sumsub-skills" \
     -H "X-Agent-Source-Ver: 1.5.0" \
     "https://api.sumsub.com${PATH_Q}"

Runnable version of that GET: examples/read-device-results.sh.

The full device-signal / risk-label catalog and where each surfaces: references/device-signals.md.

Sandbox testing

  • Sandbox has no real device signals — Fingerprint is simulated. Devices are still captured and risk labels still appear, but values are synthetic.
  • For deterministic test outcomes the module accepts a simulationConfig (FpSimulationConf) on init to force specific signals; only relevant on the self-rendered path. The prebuilt WebSDK handles sandbox simulation itself.
  • Run a full sandbox WebSDK verification (see the base skill's test docs) and confirm a device appears under the applicant's Devices tab.

Going live checklist

  • "Capture device data" is enabled on the production level (it's per-level, per-workspace — enabling it in sandbox does not carry over).
  • Your server reads device risk labels from the applicant / webhook, not from the browser.
  • If you gate access on device risk, you decided which labels are blocking vs informational (references/device-signals.md).
  • BYOK Fingerprint keys (if used) are the production keys in the prod workspace, sandbox keys only in sandbox.
  • Self-rendered path only: isDeviceIntelligenceEnabled gate, per-attemptId re-init, and X-External-Device-Fingerprint forwarding all verified against a real sandbox run.

See also

  • sumsub-integrate-websdk — the base WebSDK embed this skill sits on top of (token endpoint, lifecycle, webhooks).
  • sumsub-integrate-dint-standalone — Device Intelligence on pages with no WebSDK widget (login / signup / checkout).
  • sumsub-api-auth — HMAC signing shared by every Sumsub skill.
  • references/device-signals.md — device risk labels + where they surface.
  • examples/fisherman-self-render.ts — the advanced headless wiring.
  • examples/read-device-results.sh — read the applicant (incl. device risk labels) server-side.
  • Device Intelligence docs and Get started — authoritative source if this skill drifts.

FAQ

What does the sumsub-integrate-dint-websdk skill do?

Add Sumsub Device Intelligence (the Fisherman module) to a web project that already verifies users with the Sumsub WebSDK. TRIGGER when the user asks to "add device intelligence", "enable device capture / fingerprinting in the WebSDK", "turn on Fisherman", "detect device fraud / multi-accounting in the verification flow", or asks how device risk labels get onto an applicant verified through the WebSDK. Covers the whole loop — enabling Capture device data on the level, the automatic in-SDK Fisherman lifecycle, the advanced self-rendered wiring, reading device signals (Devices tab, Device Check, risk labels, webhooks), sandbox testing, go-live checklist. SKIP for device intelligence on pages with NO WebSDK widget (login / signup / checkout) — use sumsub-integrate-dint-standalone; SKIP for the base WebSDK embed itself — use sumsub-integrate-websdk.

How do I install sumsub-integrate-dint-websdk?

Run npx skills add https://github.com/sumsub/agent-skills --skill sumsub-integrate-dint-websdk in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/sumsub-integrate-dint-websdk/ (personal) or .claude/skills/sumsub-integrate-dint-websdk/ (project).

Which AI agents can use sumsub-integrate-dint-websdk?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is sumsub-integrate-dint-websdk safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains sumsub-integrate-dint-websdk?

It is published by sumsub in sumsub/agent-skills. It has 981 recorded installs.

More from sumsub/agent-skills

View all →

sumsub-api-auth

sumsub/agent-skills

Authenticate to the Sumsub API with an App Token + secret key (HMAC-SHA256 request signing). TRIGGER when the user asks to "call / sign / authenticate Sumsub API requests", debugs 401 Unauthorized / signature errors against api.sumsub.com, or needs a working request example with X-App-Token / X-App-Access-Sig / X-App-Access-Ts headers. SKIP only when a more specific skill in this repo (questionnaire/level/workflow/POA-preset/generic) already covers the user's actual task — those skills sign requests the same way and only need this one for auth deep dives.

Backend & APIs1.2K installs

sumsub-api-generic

sumsub/agent-skills

Catch-all fallback for any Sumsub API task that does NOT match a more specific skill (e.g. create-sumsub-level, sumsub-create-questionnaire, sumsub-api-auth). TRIGGER when the user wants to call, inspect, or debug a Sumsub API endpoint not otherwise covered — fetching applicants, listing levels, reviewing AML hits, exporting data, generating SDK tokens, anything against api.sumsub.com. The procedure — locate the right endpoint in the OpenAPI schema, read its request/response shape, build the payload, sign with App Token, and validate. SKIP whenever a narrower Sumsub skill already covers the request.

Backend & APIs1.2K installs

sumsub-check-skills-version

sumsub/agent-skills

Verify that the locally installed Sumsub agent-skills package is compatible with the published version before doing any Sumsub work. TRIGGER at the start of any task that touches Sumsub — Sumsub Dev MCP tools (mcpSumsubDev), KYC/AML workflows, applicants, checks, transactions, verification levels, verification links, questionnaires, fraud network, VASP lists, or anything Sumsub-related — so the user is warned before a stale skills package produces wrong results. Also use this skill when the user explicitly asks "are my Sumsub skills up to date / current", "is there a newer version of the Sumsub skills", or similar. Skip the actual update (the user runs npx skills add sumsub/agent-skills --all themselves) and skip any other Sumsub API or entity task — those have their own skills.

AI & Agents1.2K installs

sumsub-create-poa-preset

sumsub/agent-skills

Create or update a Sumsub Proof-of-Address (POA) preset. POST /resources/api/agent/poaStepSettings to create new, PATCH same path to update (id in body), GET /resources/api/agent/poaStepSettings/{id} to read one back. TRIGGER when the user asks to "create / add / build / configure / update / edit a POA preset" or "PoA step settings", configure which proof-of-address document types are accepted (utility bills, bank statements, tax bills, etc.), set validity periods per provider type, enable POI-as-POA (accept identity doc as proof of address), tune the cross-validator (name/address fuzzy match between POI and POA), or add per-country POA overrides. SKIP for attaching a preset to a level (set poaStepSettingsId on the level instead, via sumsub-create-level), or for non-POA presets (cross-check presets, permission presets, etc.).

Backend & APIs1.2K installs

sumsub-manage-webhooks

sumsub/agent-skills

Manage Sumsub clientWebhooks (event subscriptions for applicantReviewed / applicantPending / kytTxn / etc.) — reads via /resources/api/clientWebhooks, writes via /resources/api/agent/clientWebhooks. Sandbox only — production webhooks must be created by a human directly in the Sumsub dashboard. TRIGGER when the user asks to "list / retrieve / show webhooks", "create / add / register a webhook", or "update / edit / change a webhook target / event list / secret / signature algorithm" against their sandbox tenant. SKIP for production webhook setup (refer the user to the dashboard), for unrelated webhook surfaces (Stripe / videoIdent / Fireblocks / NFC / partner-specific receive paths under /resources/webhooks/...), for testing one-off delivery (use the inspectionCallbacks/testWebhook endpoint directly), and for KYT-only webhook routing (that's managed in the Sumsub dashboard's KYT section). The public API does not expose delete or per-webhook delivery stats — for those, refer

Backend & APIs1.2K installs

sumsub-integrate-websdk

sumsub/agent-skills

End-to-end recipe for adding Sumsub KYC to a website or web app via the Sumsub WebSDK. TRIGGER when the user asks to "integrate / embed / add Sumsub", "show the KYC widget", "add WebSDK", "verify users with Sumsub on the frontend", supplies an existing levelName they want to plug into a page, or asks how to wire up access tokens / lifecycle events / webhooks for Sumsub verification in an arbitrary project. Covers the whole loop — level setup, server-side access-token signing, snsWebSdk init (vanilla canonical, React recipe), client lifecycle events, token refresh, source-of-truth via webhooks + applicant GET, sandbox testing, go-live checklist. SKIP for building the level/questionnaire/POA-preset payload itself (use the sibling skills), or for backend-only API calls with no frontend (use sumsub-api-generic).

Backend & APIs1.2K installs

Popular ai & agents skills

View category →

google-agents-cli-publish

google/agents-cli

This skill should be used when the user wants to "publish an agent", "publish my ADK agent", "register an agent with Gemini", "publish to Gemini" (formerly Gemini Enterprise), or needs guidance on the agents-cli publish gemini command. Also use when the user wants to "manage agents in Agent Registry", "list/update/delete registered agents", or "register an MCP server". Covers ADK vs A2A registration modes, programmatic and interactive usage, flag reference, auto-detection from deployment metadata, Agent Registry fleet management, and troubleshooting. Part of the agents-cli skills suite. Do NOT use for deployment (use google-agents-cli-deploy).

AI & Agents513.9K installs

google-agents-cli-eval

google/agents-cli

This skill should be used when the user wants to "run an evaluation", "evaluate my agent", "evaluate my ADK agent", "write an eval dataset", "analyze eval failures", "compare eval results", "optimize agent", or needs guidance on the Gemini platform eval methodology and the Quality Flywheel. Covers eval metrics, dataset schema, LLM-as-judge scoring, and common failure causes. Applies to any agents-cli project, whatever framework the agent is written in. Do NOT use for agent API code patterns (ADK: use google-agents-cli-adk-code), deployment (use google-agents-cli-deploy), or project scaffolding (use google-agents-cli-scaffold).

AI & Agents513.5K installs

skill-creator

anthropics/skills

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

OfficialAI & Agents416.4K installs

codex-pet

prime-skills/runcomfy-agent-skills

Codex Pet generator on RunComfy. Build a Codex-compatible Codex Pet spritesheet.webp + pet.json from a single reference image, drop it into ${CODEXHOME:-$HOME/.codex}/pets/ / and Codex picks it up as a custom Codex Pet next to the 8 built-ins. This skill produces the exact Codex Pet atlas Codex expects (1536x1872 PNG/WebP, 8 cols x 9 rows, 192x208 cells, 9 animation states — idle, running-right, running-left, waving, jumping, failed, waiting, running, review). Calls OpenAI GPT Image 2 edit ONCE via the local RunComfy CLI as runcomfy run openai/gpt-image-2/edit to produce a canonical Codex Pet pose, then assembles all 9 animation rows programmatically with ImageMagick micro-transforms — no Codex Pro, no $imagegen, no OPENAIAPIKEY required, only RUNCOMFYTOKEN. Triggers on "codex pet", "create codex pet", "make codex pet", "hatch codex pet", "/hatch image", "desktop pet codex", "codex pets", "spritesheet.webp", or any explicit ask to build a custom pet for OpenAI Codex.

AI & Agents402.1K installs

full-output-enforcement

leonxlnx/taste-skill

Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.

AI & Agents401K installs

executing-plans

obra/superpowers

Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available

AI & Agents245.7K installs