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

# Security and Credential Management for Standalone API Keys

This article defines **security and credential management expectations** when working with **Standalone API Keys**.

It focuses on **how integrations and developers must protect API Keys**, maintain access, and respond to key lifecycle events.

## Key Security Principles

Standalone API Keys are **static credentials** with company-level access.\
Security responsibilities fall entirely on the integration and the organisation.

### Core Principles

* Treat API Keys as sensitive secrets, like passwords
* Limit exposure to only the systems that require access
* Enforce least-privilege [scope](/docs/current/authentication/api-scopes) selection
* Rotate or revoke keys promptly if compromised
* Avoid embedding keys in client-side applications

## Secure Storage

### Required Practices

Integrations **must**:

* Store API Keys encrypted at rest
* Mask keys after initial entry; never display the full key again
* Persist only on trusted backend systems
* Protect against accidental exposure in logs, error messages, or code repositories

### Recommended Storage Options

* Managed secrets vaults (e.g., AWS Secrets Manager, HashiCorp Vault)
* Environment variables for backend processes
* Encrypted database fields on server-side systems

Keys must **never** be embedded in frontend applications, mobile apps, or client-side JavaScript.

## Transmission and Handling

* Always use **HTTPS** when sending API Keys to backend systems or Pleo endpoints
* Avoid passing API Keys via query parameters; use headers where possible
* Validate API Key format before submission to reduce errors and unnecessary logging

## Permission and Scope Management

* Only request the API scopes your integration actually needs
* Do **not** assume full access unless explicitly required
* Surface permission errors clearly and prevent partial activation

Least-privilege API Keys reduce risk in case of leakage.

## Key Rotation and Replacement

Standalone API Keys may expire, be revoked, or rotated manually.

### Recommended Workflow

1. Generate a replacement key in the Pleo Web App (if allowed)
2. Update the key securely in your integration
3. Revalidate connectivity and company association
4. Remove or invalidate the previous key from your systems

Automated reminders or monitoring for key expiry are strongly recommended.

## Compromise and Incident Response

If a key is suspected to be exposed:

* Immediately revoke or replace the key
* Notify relevant teams and users
* Confirm the integration is reconnected with a valid key
* Audit logs to determine if unauthorized requests occurred

## Logging and Monitoring

* Avoid logging the full API Key
* Only store minimal identifiers for debugging (e.g., last 4 characters)
* Monitor API responses for authentication failures
* Alert users promptly when action is required

## Summary

Standalone API Keys require careful management:

* They are static, company-level credentials
* Security and lifecycle management is **integration responsibility**
* Following encryption, masking, scope limitation, and rotation best practices ensures safe and reliable access

Proper operational security complements the **UX Guidelines** and **Integration Design** to provide a complete integration strategy.

***

## What Comes Next?

* [Standalone API Key Workflow Guide](/docs/current/guides/standalone-api-keys-workflow-guide)

***

## Related Reading

* [Standalone API Keys Overview](/docs/current/authentication/standalone-api-keys-overview)
* [User Experience Guidelines for Standalone API Keys](/docs/current/integration-design/auth/api-keys/integration-design-user-exp-guidelines-for-standalone-api-keys)
* [OAuth 2.0 Overview](/docs/current/integration-design/auth/oauth/integration-design-auth-oauth-overview)

***