Block

When we return a BLOCK verdict, we have a high level of confidence that the request originated from a bad or malicious device profile.

If you'd like to allow a device or group of devices that's receiving a BLOCK verdict, you may use the Set rule endpoint to change the verdict to ALLOW for that device's identifier. Rules can also be viewed, added, removed, and modified via the Authorization rules tab within the Device Fingerprinting section of the Stytch Dashboard.

When you receive a BLOCK verdict in the Fingerprint lookup response, we recommend blocking the request(s) associated with that telemetry_id from proceeding.

We return a verdict.reasons array in the Fingerprint lookup response that will indicate the reason for the BLOCK verdict. For example, the following response indicates that the request received a BLOCK verdict because it appears to have been made from a headless browser:

"verdict": {
	"action": "BLOCK",
	"detected_device_type": "UNKNOWN",
	"is_authentic_device": false,
	"reasons": ['USER_AGENT_DECEPTION', 'HEADLESS_BROWSER_AUTOMATION']
}

If you maintain your own risk score based on cumulative DFP verdicts, we recommend assigning a high level of risk to a BLOCK verdict. You may also choose to assign different risk scores to different verdict reasons. For a list of possible reasons, please contact support.

When DFP Protected Auth is enabled in Decisioning Mode and a BLOCK verdict is returned, our SDK will always prevent the user's request from proceeding.