# Plan your integration

> Decide where to identify, how to tag actions, which keys each environment needs, and how to roll out a risk policy without surprising real customers.

Last updated: 2026-09-17

A good integration is a few decisions made up front. This page walks through them.

## Where to identify

Identify at the moments that carry risk or value, not on every page view. Each production identification is billed.

| Moment | Tag | Typical decision |
| --- | --- | --- |
| Sign-up | `signup` | Limit accounts per visitor; review high-risk sign-ups. |
| Login | `login` | Step up to a second factor on medium; lock on high. |
| Checkout | `checkout:<order id>` | Hold high-risk orders for review. |
| Promotion redemption | `promo:<code>` | One redemption per visitor. |
| Password reset | `password-reset` | Slow down resets from new, high-risk visitors. |

> **Tip:** The framework SDKs share one identification per page, so a component tree that asks several times still makes one request.

## Tag every identification

A tag binds an identification to the action it was made for. When your server checks the tag, a request ID captured on a harmless page cannot be replayed at checkout. Include an identifier from the action itself, such as an order ID, where you have one.

## Keys per environment

| Environment | Keys | Billed | Use for |
| --- | --- | --- | --- |
| Development | Public and secret | No | Laptops and CI. |
| Staging | Public and secret | No | Pre-release testing with realistic traffic. |
| Production | Public and secret, optionally a proxy key | Yes | Real visitors. |

Each environment's events, dashboards and webhooks are kept apart, so test traffic never shows up in production numbers. See [API keys and environments](https://docs.fingerly.io/docs/api-keys).

## Roll out a policy

### Step 1: Observe

Identify and store results without acting on them. Log what each level would have done.

### Step 2: Tune

Review high and medium sessions in the dashboard. Adjust [risk weights](https://docs.fingerly.io/docs/risk-weights) and the threshold until the levels match what you see.

### Step 3: Add friction first

Act on `medium` with friction a real customer can pass, such as a second factor.

### Step 4: Enforce

Act on `high` once you trust it: review, block, or limit.

> **Warning:** Never make an identification failure fatal for the visitor. If the SDK cannot reach Fingerly, let your server treat the missing request ID as missing evidence.

## Decide on the server

Always read results with a secret key on your backend. Anything the browser reports, including the score, can be changed by whoever controls the browser. See [server-side verification](https://docs.fingerly.io/docs/server-side-verification).

## Consent

The SDKs collect as soon as they are called, unless you load them with a `consent` state other than `granted`. If your legal basis requires consent, load with `pending` and pass on your consent tool's answer. See [consent tools](https://docs.fingerly.io/docs/consent-tools).

### Checklist

- Identification points chosen and tagged.
- Public key origins list every production domain.
- Secret key stored only on servers.
- Server checks the tag, the age and the level.
- Failures degrade to missing evidence, not errors.
- Consent gate in place where required.