# Integration security and data handling

Before you build an integration against the WatchEye API, review the responsibilities below. They apply in addition to the authentication, billing, and rate-limit guidance in the rest of this guide.

## Protect your API keys

Each API key is a privileged credential for your WatchEye account. A write-enabled key can read and change the records your integration is permitted to reach through the API. A read-only key can read that data without mutating it. In every case, possession of the key and secret is enough to call the API as your account.

Keep API keys and secrets safe: store them in a secrets manager or equivalent, rotate them when access requirements change, and avoid embedding them in source code or shipping them to client-side applications.

Reduce exposure by configuring **IP address or subnet restrictions** on each key in the portal ([API Keys (login required)](/documentation/account/api-keys)). A key without restrictions can be used from any internet address that has the key and secret.

## Personal information in your environment

Using the API has the potential to copy personal information (PII) from WatchEye into your application, databases, logs, backups, and any other systems that store API responses or request payloads. Each integration adds another place where that data may be held.

Personal information stored in WatchEye is covered by Global Data's security policies for the platform. Once your integration copies that information into systems you run (applications, databases, logs, and backups), protecting it becomes **your** responsibility. Global Data's platform policies apply to data in WatchEye, not to copies held in your environment.

Plan your integration with that in mind: retrieve only the fields you need, protect stored API traffic and responses, define retention that matches your compliance requirements, and treat audit logs and application logs that capture API payloads as sensitive.