An API key for one of your tools is a password to that tool's account. This page is what big does with one.

What big stores

When an admin connects an integration, big stores:

• The key itself, encrypted. More on how below.
• Which tool it's for, and the label the admin gave it.
• The account the key belongs to on the tool's side (its account id and its account name or label), as the tool reported it when big tested the key.
• The last 4 characters and a fingerprint of the key, so you can tell keys apart without seeing them. A key shorter than 20 characters gets no last 4, since 4 characters would give away too much of it; the fingerprint alone identifies it.
• Dates: when it was connected, last checked, last used and last rotated, and the code of the last error, if any.

Apart from that account id and name, big doesn't copy any of the tool's data into big in this release. It calls the tool only to test a key.

How the key is encrypted

Every key is encrypted twice over, in layers:

1. Each connection gets its own encryption key, generated fresh when you connect or rotate, and the API key is encrypted with it (AES-256-GCM).
2. That per-connection key is then encrypted ("wrapped") by a master key held in Google Cloud KMS, on hardware security modules. The master key never leaves Google's hardware, and it rotates automatically every 90 days.

To wrap and unwrap it, Google Cloud KMS receives the per-connection key, together with internal ids (the workspace, the integration and the provider) as authenticated data that ties the wrapped key to this one connection. Google never receives your API key or its encrypted form, or any other content from your workspace, so Google Cloud alone can't decrypt a key, and neither can big's database alone. That makes Google Cloud a sub-processor for this one purpose; see Your data.

Each encrypted key is also bound to its workspace, its connection and its current version, so an encrypted key copied into another workspace, or restored from before a rotation, can't be decrypted.

Only big's production service can ask Google Cloud to unwrap a key, every unwrap is logged by Google, and no person at big, engineers included, holds the permission to unwrap one. Someone with a copy of big's database would get encrypted keys they cannot open.

What you can see: the last 4 and a fingerprint

Once saved, a key is never shown again. The dashboard, the CLI, the API and both MCP servers show only:

• The last 4 characters, to recognise it at a glance. Keys shorter than 20 characters show none.
• A fingerprint, a short code computed from the key with a secret only big holds. The same key always gives the same fingerprint, so you can check "is this the key we rotated from?" without either key being shown. Because it needs big's secret, a fingerprint can't be used to test guessed or stolen keys.

Nobody can read a key back after saving: not you, not your admins, and not big staff, whatever their access. There is no reveal button and no endpoint that returns one. When you need the key again, create a new one in the tool and rotate.

Writes are dashboard-only

Connecting, rotating, re-verifying and disconnecting work only in the dashboard, signed in as an admin.

• API tokens and MCP can never read or change keys. The integrations:read scope lets a token read the status fields above and nothing else. There is no integrations:write scope to grant. A token that tries one of the write actions is refused with a message saying it is dashboard-only, and the attempt is recorded in your workspace's audit history.
• Why: a key typed into a CLI command or an agent's chat would land in shell history and chat transcripts, and a leaked API token should never be enough to swap in someone else's key or pull yours out.

Every connect, rotate, disconnect and failed test is recorded in the workspace's audit history, with the fingerprint and never the key.

Calls to your tools

• Only the tool's official API address. Each tool's address is fixed inside big No field you fill in can point big somewhere else, and big refuses to follow a redirect with your key attached.
• The tool's own error text is never shown or logged. When a test fails you get a short, fixed explanation from big, because a tool's error response can echo the key back.
• Keys are kept out of logs. big scrubs anything shaped like a key from its logs, and never logs the key, the encrypted key or the tool's response body.

Disconnect deletes the key

Disconnecting deletes the stored key immediately, together with its per-connection encryption key. What remains is the small audit record (tool, label, dates, fingerprint), kept with your workspace's audit history and deleted with the workspace. Deleting the workspace deletes every integration's key the same way.

big can't revoke a key at the tool. API keys are revoked where they were issued, so after you disconnect or rotate, delete the old key in the tool itself.

Backups

big's database backups let us restore the database to a point in the past, for a limited window. A key you disconnected therefore still exists, encrypted, inside those backups for a while, and can only be opened with Google Cloud KMS, which only big's production service can use.

It becomes permanently unrecoverable once two things have both happened:

1. The backup window has passed: NEON_PITR_DAYS days.
2. The Google Cloud master-key version that wrapped it has been destroyed. big schedules that only after the backup window has passed, and Google Cloud completes the destruction 30 days after it is scheduled.

So a disconnected key is gone for good, even from backups, within NEON_PITR_DAYS + 30 days of disconnecting.

Least privilege: the narrowest key

The safest key is one that can't do much. Each tool's page says how to create the narrowest key that tool allows, and big refuses a key that is broader than it needs where it can tell, such as a full Stripe secret key:

• Calendly: a personal access token. Calendly doesn't offer scoped tokens.
• Kit: a v4 API key.
• Stripe: a restricted key with read access to three resources only. Secret keys are refused.