One-time Secret API

What happens to a secret

The browser generates a fresh 256-bit key and encrypts UTF-8 text with AES-256-GCM before upload. Only the encrypted envelope reaches the API. The key goes in the share link's fragment, after #, so the browser does not send it in the HTTP request. The tool page loads no analytics, third-party scripts, remote fonts or remote images, and uses no local or session storage.

Every secret expires exactly 24 hours after creation. Opening a link does not consume it. An explicit reveal action releases the encrypted envelope at most once. A separate receipt token can check status or revoke the secret but cannot retrieve the message.

Create an encrypted secret

Base URL: https://aisenseapi.com/services/v1. Send POST /secret with Content-Type: application/json. No account or API key is required.

{
  "version": 1,
  "algorithm": "AES-256-GCM",
  "nonce": "BASE64URL_12_BYTE_NONCE",
  "ciphertext": "BASE64URL_CIPHERTEXT_WITH_16_BYTE_TAG"
}

This is the complete request schema. Unknown fields, plaintext and encryption keys are rejected. Use canonical, unpadded base64url. The nonce is exactly 12 bytes. The ciphertext includes the 128-bit authentication tag and represents between 1 and 16,384 bytes of plaintext. Generate a new key and nonce for each secret. Use no additional authenticated data (AAD).

{
  "secret_id": "32_LOWERCASE_HEX_CHARACTERS",
  "read_token": "64_LOWERCASE_HEX_CHARACTERS",
  "receipt_token": "64_LOWERCASE_HEX_CHARACTERS",
  "expire_timestamp": 1793275200,
  "expire_datetime": "2026-10-29T12:00:00Z"
}

Successful creation returns HTTP 201. The ID and tokens above are placeholders, not usable credentials. Keep the creation response: tokens are issued only once. expire_timestamp is Unix seconds; expire_datetime is the same expiry as an ISO 8601 UTC string. Do not put tokens or plaintext in server URLs, query strings or logs.

Build links on the client

https://aisense.no/one-time-secret#id=SECRET_ID&token=READ_TOKEN&key=BASE64URL_KEY

https://aisense.no/one-time-secret#id=SECRET_ID&receipt=RECEIPT_TOKEN

The first link contains a 32-byte encryption key, encoded as unpadded base64url, and grants access to the message. Send it only to the intended recipient through a trusted channel. Keep the second link for yourself. It grants status and revocation access and contains neither the encryption key nor the read token.

The tool validates the fragment and removes it from the address bar as the script starts. Its values remain only in page memory. Save a created link before leaving or refreshing the page. Fragment removal reduces accidental exposure; it cannot undo sharing, browser history sync, extension access or copies made elsewhere.

A modern browser, HTTPS and Web Crypto support are required. Trust in the device, browser extensions, page code and sharing channel remains necessary.

Reveal once

POST /secret/{secret_id}/reveal
Authorization: Bearer READ_TOKEN

Send an empty request body. The response is the same four-field encrypted envelope accepted at creation. Decrypt locally with the key from the share fragment, AES-GCM, its 12-byte nonce, a 128-bit tag and no AAD. Decode the plaintext as UTF-8. Render it as text, never HTML.

A GET, HEAD, link preview or receipt check must not reveal the message. The browser uses a button and sends only one reveal request per opened view. A failed response may already have consumed the message, so do not add an automatic retry or promise recovery.

Receipt and revocation

GET /secret/{secret_id}/receipt
Authorization: Bearer RECEIPT_TOKEN

POST /secret/{secret_id}/burn
Authorization: Bearer RECEIPT_TOKEN

A receipt includes secret_id, state, created_at, expire_timestamp, and delivery or revocation timestamps when applicable. created_at, delivered_at and revoked_at are ISO 8601 UTC strings; expire_timestamp is Unix seconds. Neither the encryption key nor the encrypted message is returned. The read token cannot check a receipt or revoke a secret; the receipt token cannot reveal one.

Delivered is an availability record. It does not establish recipient identity, successful decryption or human reading. A receipt may become unavailable when the record is cleaned up. Revocation cannot undo a delivery that already won a concurrent request.

Encrypted REST and MCP clients

Automated clients must perform encryption and decryption locally. The MCP interface accepts the encrypted envelope and operation tokens only. Never send plaintext, the encryption key, or a complete share link to an MCP tool, an AI conversation, or the service. MCP arguments and results can be retained by the client in conversation history; treat operation tokens as sensitive.

The browser page is the simplest way to share a message without putting its plaintext or key into an agent conversation. See the MCP server documentation for connection details.

Lifetime, storage and limits

The plaintext limit is 16 KiB measured as UTF-8 bytes, not characters. The encrypted ciphertext limit is 16,400 bytes including the tag. The complete HTTP request body is limited to 24,576 bytes. Creation allows 100 secrets per client IP per UTC calendar day, in addition to the shared request budget. There are no custom expiry settings, attachments, identities, passwords, callbacks or delivery retries.

The service stores encrypted data, hashes of the read and receipt tokens, and lifecycle metadata. It does not receive the browser encryption key or plaintext. Access ends on delivery, revocation or expiry. Encrypted records and metadata can persist until cleanup, including across service restarts; this is not a secure erasure guarantee. The service may become unavailable earlier and is not a backup.

Handle errors without losing a secret

Never automatically retry a reveal, including after a timeout or network failure: the only delivery may already have been consumed. An uncertain creation response may also leave a stored secret whose tokens were lost; another creation produces a different secret.

Never include a raw error response, token or encrypted payload in analytics. See Privacy and Terms.

Related services