Seal for sellers

You sell something digital — license keys, paid PDFs, premium templates, one-shot data. You already have your own payment processor. Seal is the delivery layer that lets you hand the goods over with the file actually consumed on receipt and proof your platform never had a re-readable copy.

Get an API key Full API docs
Scenario 1

Selling software license keys

You sell a license key for desktop software. Customer pays, your backend generates the key, you want it delivered once — to them and only them — and removed from your servers afterward.

The flow

Customer ──pays──▶ Stripe Checkout │ ▼ Stripe webhook ──▶ Your backend │ │ 1. generate license key │ 2. AES-GCM encrypt locally │ 3. POST /v1/seals (ciphertext) ▼ Seal returns id │ Build link: seal.ai-ministries.com/#/open/{id}!{key} │ ▼ Email link to customer ──▶ Customer opens once │ ▼ seal.opened webhook fires back to you │ ▼ Mark order delivered

The key step (Python)

import os, base64, requests
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# 1. After Stripe webhook fires, generate the license
license_key = generate_my_license()  # your function

# 2. Encrypt locally — server never sees plaintext
key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)
ciphertext = AESGCM(key).encrypt(nonce, license_key.encode(), None)

# 3. POST to Seal
r = requests.post(
    "https://seal.ai-ministries.com/v1/seals",
    headers={"Authorization": f"Bearer {SEAL_API_KEY}"},
    json={
        "ciphertext": base64.b64encode(nonce + ciphertext).decode(),
        "ttl_seconds": 7 * 86400,   # 7 days to open
        "max_reads": 1,             # burn after first open
        "name": "license.txt",
        "mime": "text/plain",
    }
)
sid = r.json()["id"]

# 4. Build the share URL — the key goes in the fragment
key_b64url = base64.urlsafe_b64encode(key).rstrip(b"=").decode()
share_url = f"https://seal.ai-ministries.com/#/open/{sid}!{key_b64url}"

# 5. Email it
send_email(customer.email, subject="Your license", body=share_url)

When the customer opens the link, our server fires seal.opened back to your webhook URL so you can mark the order delivered.

Scenario 2

Selling premium PDFs & templates

You sell a $19 paid guide or a Notion template. Buyer should be able to download it a few times within a window (in case they close the tab) but not forever.

The flow

Buyer ──pays $19──▶ Stripe / Lemon Squeezy / Coinbase │ ▼ Payment webhook ──▶ Your backend │ │ 1. read PDF from disk │ 2. AES-GCM encrypt │ 3. POST /v1/seals │ ttl: 7 days │ max_reads: 3 ▼ sealed link emailed

What's different

The key step (Node)

import { webcrypto } from 'crypto';
import fs from 'fs';

const pdf = fs.readFileSync('definitive-guide.pdf');

// Encrypt
const key = await webcrypto.subtle.generateKey({name:'AES-GCM',length:256}, true, ['encrypt','decrypt']);
const nonce = webcrypto.getRandomValues(new Uint8Array(12));
const ct = new Uint8Array(await webcrypto.subtle.encrypt({name:'AES-GCM',iv:nonce}, key, pdf));
const blob = new Uint8Array(nonce.length + ct.length);
blob.set(nonce, 0); blob.set(ct, nonce.length);

// Mint
const r = await fetch('https://seal.ai-ministries.com/v1/seals', {
  method: 'POST',
  headers: { 'Authorization': `Bearer ${process.env.SEAL_API_KEY}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    ciphertext: Buffer.from(blob).toString('base64'),
    ttl_seconds: 7 * 86400,
    max_reads: 3,
    name: 'definitive-guide.pdf',
    mime: 'application/pdf',
  }),
});
const { id } = await r.json();
const rawKey = new Uint8Array(await webcrypto.subtle.exportKey('raw', key));
const shareUrl = `https://seal.ai-ministries.com/#/open/${id}!${Buffer.from(rawKey).toString('base64url')}`;

// Send to buyer
await sendEmail(buyer.email, shareUrl);
Scenario 3

Anonymous tip / inbound submissions

You run a journalism shop, a security disclosure form, or a "send me a sensitive thing" inbox. You want submissions encrypted before they reach you and gone after you read them.

The flow

Submitter ──fills your form──▶ Browser (your site) │ │ 1. AES-GCM encrypt in browser │ 2. POST your /submit endpoint │ with ciphertext + key fragment ▼ Your backend │ │ 3. POST /v1/seals (ciphertext only) │ anonymously (no auth header) so │ the seal isn't tied to anyone ▼ Seal returns id │ ▼ Email YOU the share link │ ▼ You read it. It burns.

What's different

Threat model note: our server logs the IP that submitted, the same way any web service does. If you're using this for source protection where the IP itself is dangerous, advise submitters to use Tor or a public network.

Why use Seal as your delivery layer?

Get your API key Read the API docs