The terms these docs, the API and the dashboard use, and what each means precisely.
Identity
Visitor
A device as Fingerly recognises it: a browser, or an app on a phone. A visitor is not a person. Several people can share one device, and one person can use several.
Visitor ID
visitor_id. The stable identifier Fingerly issues for a visitor: twenty letters and digits, scoped to your organization. The same device on another customer's site has a different visitor ID. See visitor identification.
Visitor confidence
visitor_confidence, from 0 to 100. 100 means this exact device was seen before, 85 to 99 that it was recognised after it changed, and 0 that a new visitor ID was issued.
New visitor
visitor_is_new. true the first time your organization sees a visitor.
Identifiable
identifiable. false when a device gave too little to identify anyone. Such a device gets a new visitor ID each time, is still scored, raises fingerprint_suppressed, and costs less.
Requests and events
Identification
One call to an SDK's identify(): the SDK collects signals, the server identifies the visitor, scores the session and stores the result as an event. Production identifications are billed.
Request ID
request_id. The ID of one identification, a UUIDv7. The client sends it to your server, which reads the event with it.
Event
The stored record of an identification: the visitor, the network, the score and the signal groups that fired. Readable with a secret key for 30 days. See reading events.
Tag
tag. Your own string for an identification, such as login or checkout:8412, echoed on the event and in webhooks. Your server compares it to bind an identification to the action it was made for.
State
state. enriched when the identification was fully processed, or unavailable when the network lookup could not run, in which case nothing is scored and nothing is billed.
Deferred report
Signals a browser collects after the initial answer, attached to the same request. Archived with the event; it never changes the visitor, the score or billing.
Verdict
A local, advisory result an SDK computes on the device, such as automation or jailbreak. Useful for the interface, never for decisions. See client-side verdicts.
Risk
Signal
One thing Fingerly detects about a session, such as tor or automation. A signal's name never changes meaning.
Signal group
Signals grouped by what they tell you, such as automation in the bot group. Stored events list their triggers by group, and the dashboard reports by group. See signals.
Trigger
A signal that fired on an identification, listed in triggers with its weight and confidence. In the identify response and visitor.suspect, signal is the individual signal and group its group; on a stored event, signal is the group.
Weight
The points a signal adds to the suspect score when it fires. A whole number you can change, per platform. See risk weights.
Confidence
On a trigger, how strong the evidence for that signal was: low, medium or high. Reported alongside the weight, never multiplied into it.
Suspect score
suspect_score. The sum of the weights of every signal that fired. Not a percentage and not capped. Absent when a request was not scored, which is different from 0. See suspect score.
Threshold
The score at which the level becomes high. 30 by default.
Level
suspect_level. The score compared with the threshold: low below half of it, medium from half, high from the threshold.
Profile
A set of weights, a threshold and weighting modes for one platform. A key's own profile is used if it has one, otherwise your organization's, otherwise the defaults.
Keys and account
Organization
Your account on Fingerly: its members, keys, data, balance and region.
Environment
development, staging or production. Every key belongs to one. Only production is billed. Each environment's events, dashboards and webhooks are kept apart, while visitor IDs are shared across them. Webhooks call production live and the other two test.
Region
Where an organization's visitor data is processed and stored, such as us. Chosen once and written into every key. See regions.
Public key
fly_pk_…. Used by client SDKs to identify visitors. Accepted from browsers only on its allowed origins.
Secret key
fly_sk_…. Used by your backend to read events. Refused from browsers.
Management key
fly_mk_…. Used by your automation to manage keys, webhook endpoints and risk weights through the management API, with the permissions of the admin or developer role.
Proxy key
fly_px_…. Lets a first-party proxy forward identify requests with the visitor's real address. See proxy integrations.
Allowed origin
A scheme, host and optional port a public key is accepted from in browsers, such as https://shop.example.com. Matched exactly.
Idempotency key
The Idempotency-Key header. Sent with every retry of one identify request so it is answered and charged once. See idempotency.
Consent state
granted, pending or denied. Until it is granted, an SDK collects and sends nothing. See privacy and consent.
Micros
Millionths of a US dollar, the unit of Fingerly-Balance-Micros and billing webhooks. 3000 micros is $0.003.
Webhooks
Webhook endpoint
An HTTPS URL on your server that Fingerly sends events to, listening to live or test traffic. See webhooks.
Envelope
The JSON shape every webhook shares: id, type, version, organization_id, environment, created_at and data.
Signing secret
whsec_…. The per-endpoint secret each delivery is signed with. Verify the signature before you trust a delivery.