API REFERENCE

API Reference.

Create verifiable proofs from AI interactions.

Base URL

https://sealison.com

Authentication

Sealison exposes two endpoints with different authentication models.

POST /api/demo/prove — public demo

No API key. Hash-only mode forced server-side. Rate-limited to 5 requests per IP per hour. Use it to validate the proof flow end-to-end before requesting production access.

POST /api/prove — production

Requires an API key in the x-api-key header.

x-api-key: ck_live_a1b2c3d4

Keys are issued on request during the pre-launch period. For pilot or integration questions, email [email protected].

Endpoint

POST /api/prove

Creates a cryptographic proof of an AI interaction.

Request

Hash-only (the only accepted mode)

Clients compute the canonical hash locally and send only payload_hash to Sealison. The server never receives the original content.

Hash the canonical JSON of your payload per the Sealison canonicalization (UTF-8, Unicode NFC, CRLF/CR normalized to LF, deterministic key order; no trimming; no whitespace collapse; no BOM stripping) using SHA-256, then send the 64-char lowercase hex result.

POST /api/prove

{
  "payload_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
}

Any body containing payload, content, or mode:"full" is rejected with 400 PAYLOAD_REJECTED.

Response

{
  "proof_id": "mrb_73c50d3fa6e22d7e",
  "url": "https://sealison.com/p/mrb_73c50d3fa6e22d7e"
}

The proof URL can be shared or verified anytime.

Verification

Verification does not require the API.

Open the proof URL and paste the original content.

The hash is recomputed in the browser and compared.

Verification runs client-side from the exported proof bundle. Public CLI verifier planned.

Errors

401Missing API key
{"error": "Missing x-api-key header"}
401Invalid API key
{"error": "Invalid API key"}
400Invalid request
{"error": "Invalid payload"}
500Server error
{"error": "Internal server error"}

Notes

Deterministic hashing

The payload is canonicalized before hashing. The same input always produces the same hash.

Tamper-evident records

Any modification to the content produces a different hash. This breaks verification.

Independently verifiable

Proofs can be verified without access to the server. Integrity does not depend on SEALISON.

When hash-only fits

HASH-ONLY

Content is sensitive (PII, financial, medical)

Cannot send raw data to external services

Need audit-grade integrity guarantees

Logs show what happened.

Proofs show that it hasn’t changed.

Logs are claims.
Proof is verifiable.

HomeVerifyRetailFintechHealthcareDocsAPIQuickstart
LegalPrivacyCookies
SealisonProof, not logs.