The trust layer is
open to verify.
INKAN’s verification primitive is fully public: fetch our published Ed25519 key and check any sealed record offline, against a source we don’t control. The write side... creating consent programmatically... is in private preview while we onboard by hand.
GET /api/seal-key
Our published verification key. Returns the Ed25519 public key + key id. The private seed never leaves the server. Safe to cache and share.
curl -s https://inkan.vercel.app/api/seal-key
{
"alg": "ed25519",
"keyId": "...",
"publicKeyHex": "...",
"usage": "Verify any INKAN sealed record offline..."
}Verify a record offline
Fetch the key from a source we don’t control (committed to a public GitHub repo + served as a static file), re-derive the record’s RFC 8785 canonical JSON, then Ed25519-verify the seal. The interactive tool at /verify does exactly this in your browser.
# the key, from a source INKAN doesn't control curl -s https://inkan.vercel.app/.well-known/inkan-seal-key.json # then, offline: canonicalise the record payload (RFC 8785) # and Ed25519-verify record.sealSig against publicKeyHex. # Nothing leaves your machine; if our servers vanished, the proof holds.
POST /api/v1/consent
Programmatic consent creation. In private preview while we onboard by hand... a write today returns 202 Accepted, records your request, and our team reaches out to enable API access. It does not silently fail, and it does not pretend to have created a record.
curl -s -X POST https://inkan.vercel.app/api/v1/consent \
-H 'content-type: application/json' \
-d '{"email":"you@studio.com","organization":"Your Studio"}'
HTTP/2 202
{
"status": "accepted",
"message": "Programmatic consent creation is in private preview...",
"verify": { "sealKey": "/api/seal-key", "docs": "/developers" }
}Request API access →