AVERASE

Certificate verification

Every certificate AVERASE issues can be checked by anyone, with no account and no API key — a downstream buyer, an auditor, or a customer holding the PDF can confirm that the certificate is genuine and that its contents have not been altered since signing.

The verification endpoint is deliberately account-independent: a certificate is a portable attestation, and the people who most need to check one are usually not the people who created it. The only input is the certificate id printed on (and linked from) the certificate itself.

Certificates are only issued for successful, verified wipes — a wipe with wipe_status of completed (or legacy blank) and a validation that is approved (or blank). Failed, cancelled, or rejected wipes remain on record in /webapp/wipes but never certify.

GET/certificates/:id/verify

Verify a certificate

Public JSON endpoint. No authentication headers, no account scoping — pass the certificate id and AVERASE re-checks the record's integrity on the spot, returning the certificate's key facts alongside the verdict.

Response fields

  • Name
    valid
    Type
    boolean
    Description

    The verdict. true means the stored record still matches the tamper token computed at signing time. false with HTTP 200 means the record exists but its contents no longer match — treat the certificate as untrustworthy.

  • Name
    certificate_number
    Type
    string
    Description

    The printed certificate reference, e.g. CW-000241. Internally the certificate number is a gap-free integer sequence per account; this endpoint returns the formatted CW- string because that is what appears on the PDF a verifier is holding — the two are the same number, zero-padded to six digits.

  • Name
    account
    Type
    string
    Description

    Name of the account the certificate was issued under.

  • Name
    drive_serial
    Type
    string
    Description

    Serial number of the erased drive.

  • Name
    drive_model
    Type
    string
    Description

    Model string of the erased drive.

  • Name
    drive_capacity_gb
    Type
    integer
    Description

    Drive capacity in gigabytes (decimal units).

  • Name
    wipe_method
    Type
    string
    Description

    The sanitization method, verbatim as certified — e.g. NIST 800-88 R2 Purge.

  • Name
    passes_completed
    Type
    integer
    Description

    Number of overwrite passes completed. null for cryptographic and block erase techniques, where passes are not the unit of work.

  • Name
    completed_at
    Type
    timestamp
    Description

    When the wipe finished (ISO-8601, UTC).

  • Name
    signed_at
    Type
    timestamp
    Description

    When AVERASE signed the certificate (ISO-8601, UTC).

Request

GET
/certificates/:id/verify
curl https://averase.com/certificates/cert_01J4R3N9L4Q8RT6UWAX7ZBCDEF/verify

Response

{
  "valid": true,
  "certificate_number": "CW-000241",
  "account": "MAESON Technologies LLC",
  "drive_serial": "S6MZNF1WA04527",
  "drive_model": "SAMSUNG MZVL2512HCJQ",
  "drive_capacity_gb": 512,
  "wipe_method": "NIST 800-88 R2 Purge",
  "passes_completed": 1,
  "completed_at": "2026-08-01T14:22:07Z",
  "signed_at": "2026-08-01T14:22:09Z"
}

The three outcomes

HTTPBodyMeaning
200"valid": true + the certificate fieldsGenuine. The record matches what was signed.
200"valid": false + the certificate fieldsThe certificate exists, but the stored record has been altered since signing. Do not accept it.
404{"valid": false, "error": "not_found"}No certificate with that id exists.

The distinction between the two valid: false cases matters: a 200 with valid: false is a tampered record — the certificate id is real, but something changed the underlying data after AVERASE signed it. A 404 simply means the id is unknown (mistyped, or fabricated).

404 response

{
  "valid": false,
  "error": "not_found"
}

How the tamper check works

Each certificate is protected two ways at signing time:

  1. A tamper token. AVERASE serializes the certificate's substance into a canonical JSON payload with a fixed field order — certificate_number (as the integer), account, drive_serial, drive_model, drive_capacity_gb, wipe_method, passes_completed, started_at, completed_at, verification_hash, signed_at — and computes an HMAC-SHA256 over it with a server-side secret. The fixed order is what makes the check deterministic: the same record always serializes to the same bytes, so any change to any certified field produces a different HMAC.
  2. An Ed25519 signature. The same canonical payload is signed with a dedicated Ed25519 certificate-signing key (separate from the device-token key), and the signature travels with the certificate. The corresponding public key is published, so the signature can also be checked independently of AVERASE.

On every /verify call, the tamper token is recomputed from the record as it exists now and compared with the token stored at signing time. A match returns valid: true; any divergence — a changed serial, an edited date, a swapped method — returns valid: false.

Note the certificate_number asymmetry: the canonical payload (and webhook payloads) carry the integer, while this endpoint returns the CW-… reference string, because the verifier's source of truth is the printed certificate.

GET/certificates/:id

Download the certificate PDF

The PDF itself is served to signed-in users only, scoped to the account that owns the certificate. There is no certificates index page — the Wipes grid is the certificate listing, and its Certificate column links each CW-… reference here.

The response is a 302 redirect to a presigned R2 URL valid for 5 minutes. Certificate objects are private in storage; the presigned URL is the only way to fetch the bytes, and it expires quickly by design — re-request the endpoint for a fresh link rather than storing the URL.

If certificate generation hasn't finished yet (PDFs are rendered and signed by a background job after the wipe result arrives), the endpoint redirects back with the message:

Certificate is still generating.

Retry shortly — generation normally completes within moments of the wipe result being received.

Request

GET
/certificates/:id
curl -i https://averase.com/certificates/cert_01J4R3N9L4Q8RT6UWAX7ZBCDEF \
  -H "Cookie: <signed-in session>"

Response

HTTP/1.1 302 Found
Location: https://<r2-public-base>/accounts/<account_id>/certificates/241.pdf?X-Amz-...
  • Certificates — what a certificate contains and when one is issued.
  • Webhooks payloads — the certificate_generated event, where certificate_number is the integer and reference is the CW-… string.
  • Errors & pagination — status-code conventions across the API.

Was this page helpful?