{"id":15293,"plugin_id":"plugin_asdk_app_69d3e530928c819191a9738ef3f4def6","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:11:08.786Z","digest":"f07faaa0e7eee9aaf9151f8546d39b9d7578cb389df12604701040f29bbd0ad4","against":null,"payload":{"name":"fingerprint-rules-engine","description":"Set up no-code automatic protection with the Fingerprint Rules Engine — block or allow visitors based on Smart Signals without writing decision code — and consume the rule outcome server-side. Use when the user wants automatic protection, to build their first rule, or to enforce policy without hand-coding signal checks.","included_files":[{"relative_path":"skill.json","size_in_bytes":252}],"skill_md_contents":"---\nname: fingerprint-rules-engine\ndescription: Set up no-code automatic protection with the Fingerprint Rules Engine — block or allow visitors based on Smart Signals without writing decision code — and consume the rule outcome server-side. Use when the user wants automatic protection, to build their first rule, or to enforce policy without hand-coding signal checks.\n---\n\n# Fingerprint — Rules Engine (no-code protection)\n\nMaps to the dashboard **\"Build your first rule\"** Get Started step. The Rules Engine lets you\nblock or allow requests based on Smart Signals **in the dashboard**, without writing the decision\nlogic yourself. It's the fastest way to get automatic protection live, and it complements (doesn't\nreplace) server-side verification for your most sensitive actions.\n\n## When to use this vs. coding the checks yourself\n- **Rules Engine** — broad, policy-level protection you can change without a deploy (e.g. \"block\n  bad bots and IP-blocklisted requests on this key\"). Good default for most traffic.\n- **Server-side checks** (`fingerprint-smart-signals`) — fine-grained, per-action logic tied to\n  your business state (e.g. step-up auth only for first-time-device logins). Keep these for\n  high-risk flows.\n- Most teams use both: a ruleset for the baseline, code for the nuanced cases.\n\n> **Rules Engine is in beta and requires Server API v4.** Docs: https://docs.fingerprint.com/docs/rules-engine.\n\n## Set up your first rule (dashboard)\nThis step is configured in the dashboard, not in code:\n1. In the Fingerprint Dashboard, open **Rules Engine**.\n2. Click **+ New ruleset** (you'll see the initial \"Identify visitors\" node).\n3. Click **+ Add rule**, choose a condition on the **Visitor ID or a Smart Signal** — e.g.\n   `incognito is true` → response **block** (a simple, common first rule) — and set the\n   condition/response in the right-hand sidebar.\n\n> **Start from a template for a known use case.** Rather than building from scratch, point the user\n> at Fingerprint's prebuilt, customizable templates — Block bots, Block VPN users, Block region\n> spoofing, Account takeover (ATO) prevention, and more — at https://fingerprint.com/templates/.\n> Pick the one matching their goal and tune the signals/conditions from there.\n4. Click **Save** (top right). Use the ruleset's **Settings** tab to rename, describe,\n   enable/disable, or delete it — and to find the **ruleset ID** you'll need in code.\n\n## Rulesets are NOT attached to API keys\nThis is the key thing to get right: a ruleset is **not** bound to a public/secret API key or\nenvironment. It is evaluated only when you **explicitly pass its `ruleset_id`** to the Server API.\nWithout that parameter, the event comes back with no rule outcome — which is the usual reason a\nrule \"doesn't seem to fire.\"\n\n## Consume the outcome in code\nAfter your normal identification, fetch the event with the `ruleset_id` query parameter on the\n`GET /events/{event_id}` (v4) call — e.g. via the Server SDK `getEvent` options or directly:\n\n```\nGET https://api.fpjs.io/v4/events/<EVENT_ID>?ruleset_id=<RULESET_ID>\n```\n\nThe outcome is on the event at the root-level **`rule_action`** field:\n- `ruleset_id`, `rule_id` (the matched rule), and `type` (`\"block\"` or `\"allow\"`)\n- for block actions, the configured `status_code`, `headers`, and `body`\n\nRead it and honor it:\n- Treat a **block** `type` as a hard stop for the action.\n- Log `rule_id` so you can tune rulesets from real traffic.\n- Keep your own fail-closed checks for sensitive actions — a permissive ruleset should never\n  downgrade your code-level protection.\n\n> Guard the access — `rule_action` is only present when you passed a valid `ruleset_id`.\n\n## Verify the rule is actually working\n1. Trigger a request that should match (e.g. from a flagged bot/IP, or temporarily loosen the\n   condition).\n2. Fetch that event via `getEvent` **with `ruleset_id` passed** — not a plain `getEvent` call,\n   which won't include `rule_action`.\n3. Confirm `rule_action.type` and `rule_action.rule_id` match the rule you built.\n\n## How to apply\n1. If the user just wants automatic protection, **guide them to build the ruleset in the\n   dashboard** (steps above) — there's no SDK call to create rules.\n2. If they want to act on rule outcomes in code, pass `ruleset_id` to `getEvent` and add a check\n   on the event's `rule_action` after verification — the same place `fingerprint-smart-signals`\n   runs. Remind them a plain `getEvent` (no `ruleset_id`) returns no `rule_action`.\n3. Recommend starting from a use-case template (https://fingerprint.com/templates/) or one narrow\n   block rule (e.g. block incognito, bad bots), verifying it, then expanding — broad rules risk\n   false positives.\n\n## Best practices\n- Roll out new rules in a non-blocking/log mode first if available, then switch to block.\n- For account-level logic that needs your own data (e.g. keying off a `linkedId`/`tag`), do it in\n  code with `fingerprint-smart-signals` — rule conditions match on the Visitor ID and Smart\n  Signals, not your custom tagging metadata.\n- Don't rely on rules alone for account-level fraud — combine with server-side identity binding.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}