Quickstarts
The three calls that matter, with snippets that match the live contract exactly, the signing paths below are round-trip-verified against the published JWS test vectors. You need a vault API key and a registered request-signing key, both created in your Platform.
1 · Seal a digest
POST /v1/sealHash the document locally, then sign the request with your registered key. The JWS covers the canonical string RRv1\n{method}\n{path}\n{sha256_hex(body)}\n{ts}\n{nonce}, Rox cannot anchor in your name without it. The request is validated and either rejected immediately or accepted with 202; exactly one terminal outcome, anchored or failed, follows via webhook or polling. Store the returned salt_hex: you need it to re-verify the exact bytes later.
2 · Verify a record
GET /verify/{reference} · POST /verify/hashVerification is public by design, no key, no login. A reference lookup returns status and anchor coordinates; a digest + salt check proves the exact bytes you hold are the bytes that were sealed. One changed byte flips the result to mismatch, which the vault owner sees as a tamper signal.
3 · Register a webhook & verify its signature
POST /v1/webhooksRegistration is a JWS mutation like sealing. Every delivery is signed v1=HMAC-SHA256(secret, ts + "." + body) over the exact raw body bytes, verify it constant-time before trusting a payload, and treat verification.mismatch as your tamper alarm.