Built on a simple idea:
the server should be blind.

Every time a developer pastes an API key into Slack, email, or a ticket, that secret is at risk. It sits in inboxes, search indexes, and log files indefinitely. API KEY PRO exists to eliminate that exposure.

Why we built this

We've all done it. You need to hand off a production database password to a colleague and you paste it into a chat message, thinking you'll rotate it later. You don't. Three months later it shows up in a data breach.

Most "secret sharing" tools still store your plaintext. They just promise not to look. We wanted something different: a system where it is technically impossible for us to read your secrets, not just a policy promise. So we moved all cryptography into the browser.

The result is API KEY PRO: a dead-drop for credentials. You encrypt, we store ciphertext, the recipient decrypts, and then the ciphertext is gone forever. We never had the key.

The zero-trust model

Encrypt in the browser

When you create a secret, the plaintext is encrypted using AES-256-GCM directly in your browser via the Web Crypto API. A random 256-bit key is generated for each secret. That key never leaves your device.

Store only ciphertext

The server receives and persists only the ciphertext blob. There is no column for plaintext, no logging of raw values, and no process on the backend that can reverse the encryption without the key.

Burn on read

The decryption key travels in the share link fragment (after the #). When the recipient opens the link, their browser fetches the ciphertext, decrypts it locally, and our server permanently deletes the row. One view, then gone.

What this means for you

Use a one-time exchange for delivery and an approved password or secrets manager for ongoing storage. After consumption, the exchange cannot be opened again through the application. A recipient may still save a copy, and revoking a credential must happen at its issuing provider.

AES-256-GCM encryption using the browser's Web Crypto API.
Key in the URL fragment. The fragment is never sent to our servers by the browser.
One-time delivery: link retrieval consumes an exchange; inbox delivery confirms consumption after decryption.
7-day expiry sweep: unread secrets are automatically purged even if the link is never opened.
Workspace audit records capture exchange activity with actor and IP information.

Start for free

Product documentation by API Key Pro · Updated 29 October 2026

Our approach to secure credential delivery

API Key Pro focuses on a specific problem: transferring a sensitive value without creating a long-lived plaintext conversation history. This page describes the product's design and its limits. It is not a claim of independent certification, an external security audit or protection against every possible compromise.

Why not send a password in an ordinary message?

A password pasted into a chat or email can remain available in message history, forwarded copies and notification previews. A one-time exchange reduces the time during which a recipient can retrieve the secret from this application. That smaller retrieval window is useful, but it does not remove the need to choose a trusted recipient or revoke a credential that has already leaked.

What does zero-knowledge mean here?

For the secret payload, encryption and decryption happen in the browser and the server stores ciphertext. This does not mean the service knows nothing about an account or transaction. Operating the product still requires account information and exchange metadata. The privacy policy explains those categories. Billing providers also process payment information when you purchase a workspace.

How are encryption and authentication different?

Encryption protects the content of a message. Authentication establishes which account is using the application. API Key Pro accounts use a password and time-based one-time codes for two-factor authentication. These controls address different risks, so a secure workflow needs both. A usable bearer share link must still be protected because its possession may provide access to the linked exchange.

What does an audit log prove?

An audit log helps workspace administrators review recorded application activity, such as creating or accessing an exchange. It is not a copy of the plaintext message and cannot prove that a recipient never copied a value outside the service. References to an audit log describe application records, not a third-party assurance report or cryptographic proof that no administrator can ever alter stored data.

What should a security review include?

Review the delivery method, endpoint security, two-factor authentication, credential scope and revocation process together. Check whether the recipient's device meets your organisation's requirements. If you need contractual commitments, compliance evidence or additional controls, ask about those requirements before purchasing. Do not assume that a marketing description constitutes a certification or a signed service-level agreement.

How should teams use one-time exchange?

Create a narrowly scoped credential for the recipient rather than sharing a general administrator account.
Verify identity and the intended delivery method before sending a secret.
Use recorded exchange activity to support your review, while recognising that it does not track copies made outside the application.
Rotate or revoke credentials at their source according to your security policy, including after any suspected compromise.

Definitions and further reading

Ciphertext: The encrypted form of a message, rather than its readable plaintext.
Credential rotation: Replacing an existing password or token, and revoking the old value at its issuing service.
One-time exchange: A delivery mechanism that removes application access after consumption, not a guarantee against copying on the recipient's device.

These independent references explain the underlying concepts. They are not endorsements, certifications or an independent audit of API Key Pro.

Read our privacy policy and terms of service, or contact the team about a specific requirement.

Built on a simple idea: the server should be blind.