Good questions. Clear answers.

A device intelligence platform. It gives every visit a stable visitor ID for the device behind it, detects bots, VPNs, proxies, Tor, device farms, emulators, tampering and private browsing, and adds the findings up into a suspect score under weights you control. Your application decides what to do with it.

Teams that need to know who is behind a signup, a login, a checkout, a reward claim or a payout: fintech, e-commerce, buy now pay later, iGaming, travel, cryptocurrency, banking, marketplaces and subscription products.

Web browsers, iOS apps and Android apps, including apps built with React Native, Flutter and Lynx. On the server, a Node.js SDK reads results and verifies webhooks.

No. The API returns a visitor ID, the signals that fired and a suspect score, and never blocks a request by itself. Your application decides whether to allow, challenge, review or refuse.

No. It is an input to those decisions. Device and network context sits alongside payment authorisation, payment authentication and your fraud operations rather than replacing any of them.

Yes. The interactive demo shows a synthetic session with every check and the exact response shape. Development keys are free when you are ready to try it on your own site.

No. The SDK is not loaded on this website, and the inspector, policy sandbox and calculator run on synthetic data in your browser. There are no analytics or tracking scripts.

One identify request: a device checked at a moment you chose, such as signup, login or checkout. It is a usage event, not a monthly active user or a seat. Identify at the moments that matter rather than on every page render.

A twenty-character identifier for the device behind a request. Fingerly issues it the first time a device is seen and recognises the device on later visits, so the same device keeps the same ID. Every response carries one.

Yes, in the ordinary case. The SDKs store nothing on the device, so clearing cookies or storage does not reset the ID, and a private window is still the same device. Browsers that randomise what they report are recognised less often.

How sure the identification is, from 0 to 100. It is 100 when the device is recognised exactly, lower when the device has changed since its last visit and was still recognised, and 0 when the ID was issued on that request.

The report gave away too little to identify anyone, which is typical of a heavily hardened browser or a deliberate evasion. The request still gets a visitor ID and a score, the thin report is itself scored as fingerprint suppression, and it is charged $0.0005 instead of $0.003.

Do not assume so. A browser and a native app describe a device differently, so treat visitor IDs from the web and from your app as separate, and connect them through your own account records.

No. Visitor IDs are scoped to one organisation. The same device visiting two Fingerly customers is two unrelated visitors, and there is no cross-customer identity graph.

Fingerly does not publish an accuracy percentage. Instead, every response says how sure it is through visitor_confidence, and marks reports too thin to identify anyone with identifiable: false rather than guessing.

In browsers: automation, declared bots, virtual machines, browser tampering, anti-detect browsers, private windows and privacy settings. In apps: emulators, simulators, rooted and jailbroken devices, instrumentation, interception, cloned apps and developer tools. Everywhere: VPNs, proxies, Tor, hosting networks, abusive addresses, location mismatches, device farms and unusually high activity.

The sum of the weights of the signals that fired, returned with each of those signals, its weight and its confidence. It is not a probability. It measures how much evidence is present under your policy.

They compare the score with your threshold, which is 30 by default. A score from half the threshold is medium, a score at the threshold or above is high, and anything lower, including zero, is low.

Yes. Owners and admins set a weight for every signal and a threshold, separately for web, Android and iOS. A single SDK key can also carry its own policy through the API. Changes apply to the next request scored.

No. Both have ordinary, legitimate uses, which is why they ship with small default weights. Treat them as context alongside the device, the account and the transaction.

When the network lookup behind a request cannot run, the response is marked state: unavailable with a reason and carries no score, rather than a smaller one computed from less information. Your policy decides what to do with an unscored request.

The parts that compare devices with your own traffic learn first. They need seven days and at least 1,000 samples for an environment and platform before they add to the score. What a native app reports about its own device counts from the first request.

Yes. Development, staging and production run the same detection. Only production requests are charged.

Not automatically. Weights are the shipped defaults or the values you set. High activity and the cross-device device farm signal learn what is unusual from your traffic, but the weights stay under your control.

Accessibility services are never counted as a sign of automation. Privacy tools such as VPNs, private windows and privacy-focused settings are reported as context with small default weights, and none of them is designed to decide an outcome on its own.

A JavaScript SDK for browsers with bindings for React, Next.js, Vue, Nuxt, Svelte and Angular; native iOS and Android SDKs with React Native, Flutter and Lynx bridges; a Node.js SDK for servers; and a Cloudflare Worker proxy.

The packages are not on public registries yet. Talk to the team to get access for your platform while they are prepared for release.

Both are planned. Until then the server side is two HTTPS calls and one HMAC check: read an event with your secret key, and verify webhook signatures with HMAC-SHA256.

Neither. The SDKs write no cookies and nothing to browser storage, and never show a permission prompt, picker or dialog on any platform.

Identify answers after an initial collection budget of 300 milliseconds. Slower work continues separately afterwards and never changes the identification, the score or the charge.

At the moments that matter: signup, login, checkout, a reward claim, a payout. Not on every page render. The framework bindings share one identification across a page, so several components asking cost one request.

Yes. The React, Next.js, Vue, Nuxt, Svelte and Angular bindings identify only after the page reaches the browser, so a server render shows the unidentified state and nothing needs guarding.

Serve it from your own domain with a first-party proxy: createProxy in the Node.js SDK, or the Cloudflare Worker. The proxy authenticates with its own credential and forwards the visitor’s real address, so network signals stay accurate.

Do not. Send only the request ID to your backend, read the stored event there with a secret key, check that its tag matches the action, and decide. Secret keys are refused if they are used from a browser.

With a key in the x-api-key header. Public keys are used by the SDKs and must come from an allowed origin in a browser. Secret keys are for your backend: they read events and are refused if a request carries a browser Origin.

Organisations start at 1,000 requests a second across all their keys. Past it, requests are refused with a 429 and a Retry-After header. Talk to the team if you expect more.

Not if you send an Idempotency-Key. A retry with the same key is answered once, marked duplicate, and charged once.

Events can be read in the console and through the API for 30 days. A list returns up to 200 events a page.

identification.completed for every identification, visitor.suspect when one lands at the high level, identification.refused when a request is refused, billing.status_changed when your organisation starts or stops accepting traffic, and usage.daily_settled when a day of usage is settled.

Compute HMAC-SHA256 of the timestamp header, a dot and the raw body with the endpoint’s signing secret, compare it with the signature header in constant time, and reject timestamps older than five minutes. The Node.js SDK does this in one call.

Failed deliveries are retried after 30 seconds, 2 minutes, 10 minutes, 1 hour and 6 hours. A 410 Gone response stops them. Every attempt is kept in the delivery history for 30 days.

Up to ten per organisation. Each listens to one environment and the event types you choose, must use HTTPS, and gets its own signing secret, shown once.

A production identification is $0.003. A production request that cannot be identified is $0.0005. There are no plans, seats or monthly fees.

Development and staging keys are always free, and every new account starts with $3 of credit, enough for 1,000 production identifications. The signup credit is given once per email address.

No. The signup credit needs no card. Add funds from $5 when you are ready for production traffic.

Development and staging requests, retries of the same request, refused requests, requests whose network lookup failed, and reading results from your server.

By card. Add funds from $5 to $5,000 at a time, and production requests spend from the balance.

Save a card, choose a threshold and an amount between $5 and $5,000. When the balance falls below the threshold, the card is charged that amount. By default it runs at most three times a day, five minutes apart, and pauses after three declined charges in a row.

Production requests are refused with a 402 until you add funds, so nothing arrives as a surprise bill. A burst can take the balance slightly below zero before requests pause, and your next top-up settles it.

No. Credit you buy and your signup credit never expire. Only a promotional grant has an end date, and it says so when it is given.

No. An identification is $0.003 at every volume, and there is nothing to commit to. You fund only what you use.

In the data region chosen when your organisation is created. The United States region is available today and the European Union region is coming soon. Accounts and billing are kept separately from visitor data.

No. The organisation owner chooses the region once, and it is fixed from then on.

Characteristics of the device and browser or app, used to recognise the device and to tell whether it is being misrepresented. They do not read page content, form fields, keystrokes, mouse movement, the clipboard, contacts, photos or location services.

No. Visitor data is not sold, not shared between customers and not used for advertising or marketing of any kind.

You decide the notice, the legal basis and any consent your visitors need, and the SDK collects as soon as it is called. The SDKs have no consent option yet, so only initialise them once you have the basis you decided on. Have your privacy and legal teams review the implementation.

Events can be read for 30 days. Retention limits for the device identity index and the full event archive are not in place yet, so do not promise a shorter retention period in your own privacy notice than the platform keeps.

Write to the team. Erasure requests are handled on request today; there is no self-service erasure API yet.

Secrets are shown once and stored only as keyed hashes. Public keys work only from the origins you list, secret keys are refused from browsers, and keys can be revoked at any time.

No. No privacy or security certification is claimed.

Sign up in the console and choose your data region. The account starts with $3 of credit, and you can issue free development keys straight away.

Four. The owner can do everything, including transferring the organisation. Admins can do everything else. Developers issue keys and manage webhooks. Billing members manage payment methods and top-ups.

No. There are no seat charges. Invite the whole team.

Write to support@fingerly.io with your organisation’s name, the environment and key prefix involved, and any request IDs. Never send a secret key.