MegTrustDevelopers

Generate keys

You hold the private key. We only ever see the public one.

Create your keypair

Requests are signed with Ed25519. You generate the keypair; the private key never leaves your machine, and MegTrust stores only the public key — which can verify your signatures but can never create one. Even a breach of our systems could not forge a request as you.

# Writes megtrust-private.pem and prints your PUBLIC key:
node -e 'const c=require("crypto"),f=require("fs");const{publicKey,privateKey}=c.generateKeyPairSync("ed25519");f.writeFileSync("megtrust-private.pem",privateKey.export({type:"pkcs8",format:"pem"}),{mode:0o600,flag:"wx"});console.log(publicKey.export({type:"spki",format:"der"}).toString("base64"))'

The command refuses to overwrite an existing megtrust-private.pem, and writes it readable by your user only.

Prefer OpenSSL? openssl genpkey -algorithm ed25519 … works on OpenSSL 3.x, but macOS ships LibreSSL, which does not support Ed25519 here — use the Node command above.

Register the public key

Ask your organisation administrator to open Developers → API keys in the console of the intended environment. Paste the printed public key to get your Key ID.

Keep megtrust-private.pem in your server's secret manager — never in browser code, a mobile app, a prompt, or version control.

What a key can reach

  • Each key is fixed to one workspace, without its child workspaces.
  • Expiry, revocation and any configured IP allowlist apply to every request.
  • Use separate keys and private key files for each environment and each integration. Giving each service its own key also means one busy job can't throttle another (see Rate limits).
  • These keys belong to MegTrust's client API. No other credentials are needed.

Rotate a key

  1. Generate a new keypair and register the new public key.
  2. Switch your integration to the new Key ID and private key.
  3. Verify a signed read, for example GET /api/v1/wallets.
  4. Revoke the old key in the console.

Legacy HMAC keys

Older integrations may hold an HMAC secret instead of an Ed25519 key. They sign the same canonical string (see Sign a request) with HMAC-SHA256, keyed by the issued secret string (do not hex-decode it), and send it as exactly 64 lowercase hex characters. New integrations should use Ed25519.

On this page