Every identification returns a visitor ID for the device behind the session. It is issued once, recognised on every later visit, and stays the same when cookies are cleared, a private window opens or the network changes.
A name for the device, not for the visit. The SDK describes the browser or app, and the server decides who it is. The identifier is issued by Fingerly rather than computed in the page, so a visitor cannot forge one and recognition improves without an SDK release.
The identification half of every identify response. The suspect score and the signals behind it arrive in the same body.
visitor_idstringvisitor_is_newbooleanvisitor_confidenceinteger, 0 to 100identifiableboolean{
"request_id": "01a0a84b-e6a2-7c09-9f51-0b3d7a26c8e4",
"visitor_id": "X9pL2mRc7KvT4bQw8NdF",
"visitor_is_new": false,
"identifiable": true,
"visitor_confidence": 100,
"state": "enriched",
"suspect_score": 0,
"suspect_level": "low"
}Every identifier on this page is synthetic.
Devices change a little every week. The visitor ID is designed to stay put through ordinary change, and to say plainly when it cannot.
The SDK writes nothing to the device, so there is nothing to clear. The identifier is remembered on Fingerly’s side.
Identity does not depend on browser storage, so a private window is still the same device. It can also be reported as incognito.
Moving from home wifi to mobile data does not change the ID. The address feeds the network signals and is never part of identity.
A browser update or a new monitor changes a device a little. It is still recognised, with a confidence that says how exactly.
Browsers that randomise what they report are recognised less often. When too little is left, the response says identifiable: false instead of guessing.
A device that visits two Fingerly customers is two different visitors. Identifiers are scoped to one organisation.
A visitor ID earns its keep wherever something should happen once per person, and wherever a familiar device should skip a hoop.
Connect the fifth signup to the first four.
Store the visitor ID with every new account. A device that keeps creating accounts is visible the moment it tries again, before a trial or a credit is granted.
Skip the hoops for familiar devices.
A customer on the laptop they always use can skip the second factor. Keep the step-up for a device the account has never signed in from.
One welcome offer per device.
Coupons and referral rewards are meant once per person. Count claims per visitor ID and review the devices that keep coming back for more.
A meter that follows the reader.
A cookie-based article meter resets in a private window. A meter keyed on the visitor ID does not.
Prepaid and pay as you go. Every signal and the suspect score are included in the same request.
| Outcome | Price | When it applies |
|---|---|---|
| Identification | $0.003 | The device was identified |
| Request we can’t identify | $0.0005 | Too little to identify; the network picture is still returned |
| Development and staging | $0 | Every request made with a non-production key |
Prices in USD, excluding taxes. Retries of the same request are charged once.
No. The SDKs write no cookies and nothing to local storage or IndexedDB. The identifier is issued and remembered on Fingerly’s side, so clearing browser data does not reset it.
Every response says so. visitor_confidence is 100 when the device is recognised exactly and lower when it has changed since its last visit. Browsers that randomise what they report are recognised less often, and a report too thin to identify anyone is marked identifiable: false rather than guessed.
No. Visitor IDs are scoped to a single organisation. The same device visiting two Fingerly customers is two unrelated visitors.
Yes. Native iOS and Android SDKs send the same identify request from apps, and the React Native, Flutter and Lynx bridges call those native SDKs. Every platform receives the same response fields.
Start with the signals, keep your own decisions, and pay only for what you identify. No credit card needed.