Introduction

HideGuard measures the browser on your page, the address it arrives from, and how it behaves — and returns a verdict your backend can act on: allow, challenge or block.

The question it answers#

One question, asked where something of value changes hands: is this visit trustworthy?

The answer is not a label stuck on a person. It is the sum of several independent measurements — whether the browser has been modified, whether the address is a proxy or a datacenter, what this browser's payment history looks like — each carrying its own weight, adding up to a score from 0 to 100.

How the arithmetic works is in Verdict and score.

What it does not do#

Three things, all of them deliberate.

It does not decide for you. block is a weighted recommendation, not an action. Your page is still where the refusal happens, because only you know what that order is worth and what a wrong refusal costs.

It never turns a missing measurement into a clean one. When a check could not run, the result is unmeasured, not measured and fine. That rule shapes every number on every screen and is worth reading on its own: Measured and unmeasured.

It does not store a verdict as a fact. What is stored is the raw signals. When the scoring model changes, all of history is re-scored under the new one. A record saying "this person is a bot" could never be re-scored.

The two halves of an integration#

The browser SDK — one <script> tag on your page. It measures, posts, and receives a verdict. It also sets an fpc_vid cookie on your own domain, so your backend knows which browser is asking.

The server-side check — your backend calls POST /api/v1/verdict before accepting anything important. This is the half that can actually refuse: the verdict the SDK hands the page is advisory, and a scripted client never runs it at all.

Start at Quickstart, or read How it works first if you would rather understand the path of the data before writing any code.