> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fingerprint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Get server side intelligence

Fingerprint client agents (for example, the [JavaScript agent](/reference/js-agent-v4)) allow you to get the visitor ID on the client. However, client-side code can always be tampered with, so we recommend processing Fingerprint results securely on your server. Fingerprint also intentionally limits the information available in the [client response](/reference/js-agent-v4-get-function#get-response). Information related to fraud protection like [Smart Signals](/docs/smart-signals-introduction) is only available on the server.

Fingerprint offers three methods for getting device intelligence to your server:

* [Sealed Client results](#sealed-client-results) (real-time processing)
* [Events API](#events-api) (near real-time processing)
* [Webhooks](#webhooks) (asynchronous processing)

All methods provide the same information but have different trade-offs in latency and implementation complexity. Read below to choose the best method for your use case.

<Note>
  **Server integrations are free**

  Getting device intelligence to your server is *free*. Querying for an event through our APIs or receiving a webhook does not come at any additional cost.
</Note>

## Sealed Client Results

If your application needs to make a decision or take action as soon as Fingerprint results are available, your best option is to use [Sealed Client Results](/docs/sealed-client-results).

* Using this method, Fingerprint sends the full encrypted payload to the client.
* The encryption ensures that it cannot be altered by malicious actors.
* Your client forwards the payload to your server where you can decrypt and process it without any additional API calls.

Compared to the [Events API](/reference/server-api-v4-get-event), integrating Sealed Client Results involves additional steps like creating and managing decryption keys. But if you want to get the best end-to-end performance, they should be your first choice.

## Events API

A simpler alternative for real-time processing is to use our [Server API](/reference/server-api-v4).

* Using this method, your client sends the  `event_id` from the Fingerprint client agent to your server.
* On the server, you can use the Server API  [`/v4/events/:event_id`](/reference/server-api-v4-get-event)  endpoint to get the full device intelligence result.

Compared to [Sealed Client Results](/docs/sealed-client-results), this setup requires one additional API call which might translate into higher latency.

## Webhooks

If real-time processing is not required, we offer [Webhooks](/docs/webhooks) to send the device intelligence results to you automatically and asynchronously.

* Using this method, you give Fingerprint a URL of your server endpoint for processing webhooks.
* For every identified visitor, Fingerprint will send the full device intelligence result to your server endpoint.

Typical applications of Webhooks include storing a copy of every result for further processing or increasing security through the [Zero Trust Mode](/docs/zero-trust-mode).

## Protecting from tampering and replay attacks

None of the mechanisms above protect from replay attacks. It's up to you to implement it separately on your backend.

See [Protecting from client-side tampering and replay attacks](/docs/protecting-from-client-side-tampering) to learn about additional security measures you can take to protect your Fingerprint implementation.

## Multiple environments

If you use multiple environments to separate your Fingerprint setup for different domains or apps, you might want to get events to your server also separated by environments - in case you have different servers processing events for different environments.

All methods mentioned above (Sealed Client Results, Events API, Webhooks) fully support multiple environments.

* You can issue a dedicated **Encryption key** per environment, enabling Sealed Client Results only on selected environments.
* **Secret keys** used to authenticate with Server API can be scoped to environment, making `/v4/events` endpoints returning only events associated with the same environment.
* When creating **webhooks**, you can scope them to an environment, making the webhook send only events associated with the same environment.

See the guide on [multiple environments](/docs/multiple-environments) to learn how to set up environment-scoped resources.