Event types

AVERASE fires six webhook event types. This page covers each one: when it fires, the record type it carries, and what the payload looks like.

Every payload is the standard envelope — event_id, event_type, created_at — with the record's fields flat at the top level. Field-by-field schemas live on the Payloads page.

Event type	Record `type`	Fires when
`wipe_session_ready`	`wipe_session`	A pre-wipe check-in is allowed
`wipe_session_blocked`	`wipe_session`	A boot verification or pre-wipe check-in is denied
`asset_reported`	`asset_report`	A machine boots from AVERASE for the first time
`hardware_tests_completed`	`hardware_test_report`	An operator submits hardware test results
`wipe_session_completed`	`wipe_report`	A wipe result is received — pass or fail
`certificate_generated`	`certificate_report`	A certificate is signed and its PDF uploaded

Three of these are the mandatory core every integration should handle, because together they carry the complete machine story: asset_reported creates the machine's record (first boot, every hardware test still Not started), wipe_session_completed records each drive's erasure, and hardware_tests_completed updates the machine's record with Pass/Fail test outcomes. The session signals and certificate_generated are auxiliary — useful, but nothing else depends on you consuming them.

wipe_session_ready

Fires when a device's pre-wipe check-in is allowed — a wipe has been authorized and metered against the license token's quota, and is about to start. The record's id is the session's job_id; the same UUID will show up as job_id (and report_id) on the eventual wipe_report, which is how you tie a completed wipe back to its authorization.

Name
id
Type
uuid
Description
The session's job_id.
Name
type
Type
string
Description
Always wipe_session.
Name
status
Type
string
Description
Always ready.
Name
job_id
Type
uuid
Description
Same value as id.
Name
license_token_id
Type
string
Description
The ltok_… license token that checked in.
Name
quota_remaining
Type
integer or null
Description
Wipes left on the token after this check-in; null means unlimited.

This event describes a moment, not a record — it is never backfilled by reconciliation.

Example payload

{
  "event_id": "b2c3d4e5-f6a7-4890-8b1c-2d3e4f5a6b7c",
  "event_type": "wipe_session_ready",
  "created_at": "2026-08-12T17:02:44Z",
  "id": "0e6f4a8c-2d1b-4e5f-9a7c-8b6d5e4f3a2b",
  "type": "wipe_session",
  "status": "ready",
  "job_id": "0e6f4a8c-2d1b-4e5f-9a7c-8b6d5e4f3a2b",
  "license_token_id": "ltok_01J4QY7R5N8T2VW9XA3BC4DEFG",
  "quota_remaining": 4,
  "updated_at": "2026-08-12T17:02:44Z",
  "revision": 1786813364
}

wipe_session_blocked

Fires when a device is denied — either at boot verification (phase: "verify", unmetered) or at the pre-wipe check-in (phase: "checkin", the metered call). Useful for alerting: a blocked check-in means a technician is standing at a machine that will not wipe.

Name
id
Type
uuid
Description
A one-off UUID minted for this event — blocked sessions have no durable record, so the id never recurs.
Name
type
Type
string
Description
Always wipe_session.
Name
status
Type
string
Description
Always blocked.
Name
phase
Type
string
Description
verify (boot unlock) or checkin (pre-wipe).
Name
reason
Type
string
Description
Why it was denied: revoked, suspended, disabled, account_inactive, or quota_exceeded.
Name
license_token_id
Type
string
Description
The ltok_… token that was denied.
Name
token_status
Type
string
Description
The token's status at the time. Note this can be active when the denial is about the account or quota rather than the token itself.

Like wipe_session_ready, this is a moment, not a record — it is never backfilled. If your endpoint is down when the denial happens, the event is gone.

Example payload

{
  "event_id": "c3d4e5f6-a7b8-4901-8c2d-3e4f5a6b7c8d",
  "event_type": "wipe_session_blocked",
  "created_at": "2026-08-12T17:05:19Z",
  "id": "9a8b7c6d-5e4f-4a3b-8c2d-1e0f9a8b7c6d",
  "type": "wipe_session",
  "status": "blocked",
  "phase": "checkin",
  "reason": "quota_exceeded",
  "license_token_id": "ltok_01J4QY7R5N8T2VW9XA3BC4DEFG",
  "token_status": "active",
  "updated_at": "2026-08-12T17:05:19Z",
  "revision": 1786813519
}

asset_reported

Fires once, on the machine's first boot from the AVERASE USB device — the moment the machine enters your inventory, before any wipe. Subsequent boots update the stored record silently and do not re-fire the event (a reconciliation backfill may re-send it, with the same id and a higher revision). The record is the full asset_report: the machine's identity, firmware, CPU, memory, and display scalars flat at the top level, plus typed child arrays for memory, network, storage (controllers), disk (drives, with SMART data), video, audio, port, battery, and test_result.

The test_result array is present from the start and always carries the full hardware-test catalog — keyboard, display, USB ports, battery, Wi-Fi adapter, Bluetooth, webcam, audio, touchscreen — with every row Not started, since no tests have run at first boot. Test outcomes arrive later as hardware_tests_completed events that update this same record.

The id is the asset's stable asset_… identifier, keyed to the physical machine (DMI UUID + serial). This is the largest record — its complete schema, field derivations, and a full example are on the Payloads page.

Example payload (child arrays truncated)

{
  "event_id": "3f7a2b9c-8d1e-4a5f-b6c7-d8e9f0a1b2c3",
  "event_type": "asset_reported",
  "id": "asset_01J4QZ8T2M9V6XW3YB5NC7DEFG",
  "type": "asset_report",
  "created_at": "2026-08-12T16:58:11Z",
  "updated_at": "2026-08-12T16:58:11Z",
  "deleted_at": null,
  "uploaded_at": "2026-08-12T16:58:11Z",
  "revision": 1786813091,
  "software_version": "0.9.0",
  "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
  "report_id": "CW-20260812-000117",
  "batch_name": "2026-08-12",
  "system_vendor": "Dell Inc.",
  "system_model": "Latitude 5540",
  "system_serial": "74HRKY3",
  "cpu_model": "13th Gen Intel(R) Core(TM) i5-1335U",
  "cpu_speed_display": "4.60 GHz",
  "memory_total_capacity_display": "16.00 GB",
  "memory": [],
  "network": [],
  "storage": [],
  "disk": [],
  "video": [],
  "audio": [],
  "port": [],
  "battery": [],
  "test_result": [
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "keyboard",
      "name_display": "Keyboard",
      "result_display": "Not started",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "display",
      "name_display": "Display",
      "result_display": "Not started",
      "notes": ""
    }
  ]
}

Full asset_report schema

hardware_tests_completed

Fires when an operator runs hardware tests on the erasure engine and the kiosk submits the results. The record's id is the machine's asset id — the same asset_… value as its asset_reported event — so apply it as an update to that record: this event is how the machine's tests move from the Not started rows shipped at first boot to Pass / Fail.

Each submission replaces the previous snapshot in full, and the test_result array always carries the complete test catalog: tests the operator hasn't run stay in the array as Not started (or Not applicable where the hardware doesn't exist — a desktop has no battery or touchscreen). Never treat it as a diff; the latest event is the whole current state.

Example payload

{
  "event_id": "a7b8c9d0-e1f2-4345-8a5b-6c7d8e9f0a1b",
  "event_type": "hardware_tests_completed",
  "created_at": "2026-08-12T17:15:22Z",
  "id": "asset_01J4QZ8T2M9V6XW3YB5NC7DEFG",
  "type": "hardware_test_report",
  "updated_at": "2026-08-12T17:15:22Z",
  "revision": 1786814122,
  "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
  "report_id": "CW-20260812-000117",
  "system_vendor": "Dell Inc.",
  "system_model": "Latitude 5540",
  "system_serial": "74HRKY3",
  "test_result": [
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "keyboard",
      "name_display": "Keyboard",
      "result_display": "Pass",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "display",
      "name_display": "Display",
      "result_display": "Pass",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "usb_ports",
      "name_display": "USB Ports",
      "result_display": "Not started",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "battery",
      "name_display": "Battery",
      "result_display": "Pass",
      "notes": "94% health"
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "wifi_adapter",
      "name_display": "WiFi Adapter",
      "result_display": "Pass",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "bluetooth",
      "name_display": "Bluetooth",
      "result_display": "Not started",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "webcam",
      "name_display": "Webcam",
      "result_display": "Fail",
      "notes": "no image"
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "audio",
      "name_display": "Audio",
      "result_display": "Pass",
      "notes": ""
    },
    {
      "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
      "name": "touchscreen",
      "name_display": "Touchscreen",
      "result_display": "Not applicable",
      "notes": ""
    }
  ]
}

Because asset_reported fires only at first boot, this event is the only way test outcomes reach you afterwards — subscribe to both and upsert on the shared asset_… id to keep a machine's record complete.

wipe_session_completed

Fires on the first receipt of each wipe result — one event per drive, for successes and failures alike (status_display of Completed, Failed, or Cancelled; check erase_result_display, which is Pass only for completed wipes). Wipe result submission is idempotent on job_id, so a device retrying its upload does not re-fire the event.

The record is a wipe_report: the drive's identity, the erasure algorithm and technique, timings, verification, and — when the drive was matched by serial to a reported machine — that machine's hardware_id, asset_id, and system_serial (all null for hotswap wipes and never-reported machines).

Full example payload

{
  "event_id": "d4e5f6a7-b8c9-4012-9d2e-3f4a5b6c7d8e",
  "event_type": "wipe_session_completed",
  "id": "wr_01J4R2M8K3P7QS5TV9WX6YZABC",
  "type": "wipe_report",
  "product": "engine",
  "created_at": "2026-08-12T17:41:08Z",
  "updated_at": "2026-08-12T17:41:08Z",
  "deleted_at": null,
  "revision": 1786815668,
  "hardware_id": "4c4c4544-0034-5a10-8052-b9c04f4b5933/74HRKY3",
  "asset_id": "asset_01J4QZ8T2M9V6XW3YB5NC7DEFG",
  "report_id": "0e6f4a8c-2d1b-4e5f-9a7c-8b6d5e4f3a2b",
  "job_id": "0e6f4a8c-2d1b-4e5f-9a7c-8b6d5e4f3a2b",
  "batch_name": "2026-08-12",
  "vendor": null,
  "model": "SAMSUNG MZVL2512HDJD-00BL2",
  "serial": "S64FNE2R504071",
  "capacity_bytes": 512000000000,
  "capacity_display": "512 GB",
  "erase_algorithm": "nist_800_88_r2_purge",
  "erase_algorithm_display": "NIST 800-88 R2 Purge",
  "erase_technique": "NVMe Sanitize — crypto erase",
  "erase_level": "Purge",
  "status_display": "Completed",
  "erase_result_display": "Pass",
  "erase_start_time": "2026-08-12T17:03:01Z",
  "erase_finish_time": "2026-08-12T17:40:58Z",
  "erase_duration_seconds": 2277,
  "erase_duration_display": "00h37m",
  "wipe_status": "completed",
  "passes_completed": null,
  "validation": "approved",
  "disposition": "sanitized",
  "markings_removed": true,
  "tool_components": "nvme-cli 2.4",
  "verification_result": "Pass — 32/32 fingerprint sectors overwritten",
  "verification_hash": "1f7c9d0a4b2e8f6c3a5d7e9b1c4f8a2d6e0b3c7f9a1d5e8b2c6f0a4d7e9b1c4f",
  "certificate_status": "pending",
  "certificate_url": null,
  "license_token_id": "ltok_01J4QY7R5N8T2VW9XA3BC4DEFG",
  "operator": "J. Ramirez",
  "system_serial": "74HRKY3"
}

Don't wait on certificate_status — at delivery time it is usually still pending, because the certificate PDF is generated asynchronously. The certificate announces itself via its own certificate_generated event.

Full wipe_report schema

certificate_generated

Fires when a certificate of erasure has been signed and its PDFs uploaded — the final event of a successful session. Certificates are only issued for successful, verified wipes, so a failed wipe produces a wipe_session_completed event but never a certificate_generated.

Name
id
Type
string
Description
The certificate's cert_… identifier.
Name
type
Type
string
Description
Always certificate_report.
Name
certificate_number
Type
integer
Description
The certificate's sequence number — an integer here (e.g. 118). The human-readable form lives in reference.
Name
reference
Type
string
Description
The CW-… reference string (e.g. CW-000118) — the form shown in the web application and returned by the public certificate verification endpoint (which, confusingly, calls it certificate_number).
Name
wipe_result_id
Type
string
Description
The wr_… wipe result this certificate covers.
Name
job_id
Type
uuid
Description
The session's job_id — joins back to wipe_session_ready and the wipe_report.
Name
drive_serial
Type
string
Description
Serial of the erased drive.
Name
pdf_url
Type
string or null
Description
URL of the signed certificate PDF. Set once the upload finishes — and since this event fires after the upload, it is populated here.
Name
signed_at
Type
timestamp
Description
When the certificate was signed.

Example payload

{
  "event_id": "e5f6a7b8-c9d0-4123-8e3f-4a5b6c7d8e9f",
  "event_type": "certificate_generated",
  "created_at": "2026-08-12T17:41:11Z",
  "id": "cert_01J4R2NA7Q4XS8TW2VY5ZBCDEF",
  "type": "certificate_report",
  "certificate_number": 118,
  "reference": "CW-000118",
  "wipe_result_id": "wr_01J4R2M8K3P7QS5TV9WX6YZABC",
  "job_id": "0e6f4a8c-2d1b-4e5f-9a7c-8b6d5e4f3a2b",
  "drive_serial": "S64FNE2R504071",
  "pdf_url": "https://<r2-public-base>/accounts/acct_bzXq9KrLEMm32iAnOP0xGDYk/certificates/118.pdf",
  "signed_at": "2026-08-12T17:41:10Z",
  "updated_at": "2026-08-12T17:41:11Z",
  "revision": 1786815671
}

Anyone can validate a certificate — without authentication — at GET /certificates/:id/verify.