Developers

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.

Live

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..."
}
Live

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.
Private preview

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 →