API reference
AVERASE exposes a small, deliberate API surface: a read-only JSON API for pulling your asset inventory into other systems, a public endpoint for verifying certificates, signed webhooks for push delivery, and an internal API that only the erasure devices themselves talk to. This page maps the whole surface and gets you to a first successful request.
The API surface
The Asset API (/api/v1/…) is the integration surface — a read-only JSON API for syncing your asset inventory and account details into external systems. It is designed for poll-based incremental sync: your integration polls on whatever schedule suits it, asks only for what changed since its last run, and upserts the results. It never mutates anything in AVERASE. See Accounts and Assets.
Certificate verification (GET /certificates/:id/verify) is public JSON — no authentication at all — so anyone holding a certificate can confirm it is genuine and untampered. See Certificate verification.
Webhooks are the push counterpart to the poll-based Asset API: AVERASE delivers signed JSON events (assets reported, wipes completed, certificates generated, and more) to your endpoint the moment they happen. See Webhooks.
The internal API (/internal/…) is machine-facing: it is how the erasure engine and hotswap station verify their device tokens, check in before wipes, and report hardware and wipe results — always through the engine Worker, never directly from your systems. It is documented for operators and auditors, not for integration use. See Internal API and the Engine Worker API.
The sandbox is a hosted mirror of the whole surface for building integrations without touching a real account — it lives at https://api.averase.com (or run your own copy locally). See Sandbox.
The Asset API is read-only by design. Nothing you can send it creates, changes, or deletes data in AVERASE — writes only ever come from the erasure devices themselves, through the internal API.
Getting an API key
API keys are minted in the web application under Settings → API tokens (/api_tokens). Only account admins can create or revoke them, and every key is scoped server-side to exactly one account — the account it was created in is the only account it can ever read. Create one key per integration and name it after the system that will use it, so the Last Used column stays meaningful.
See Authentication for the full token model, headers, and error behavior.
Base URL
All examples on these pages use https://averase.com as the host — substitute your AVERASE host. The sandbox uses https://api.averase.com with the same paths.
Recommended sync pattern
The Asset API is built around one pattern: keep a cursor, ask for everything updated since it, and upsert by id.
Sync loop
cursor = timestamp of your last successful run's START
every run:
run_started_at = now
page = 1
loop:
GET /api/v1/assets?account_id={account_id}&since={cursor}&page={page}
upsert each asset into your system by its "id"
(optionally GET /api/v1/assets/{id} for the full fingerprint)
stop when page == pages
page += 1
persist cursor = run_started_at
Persisting the run's start time (not its end time) as the new cursor means an asset updated mid-run is picked up again next run instead of slipping through the gap. Upserting by id makes that harmless — you just refresh the same row. Any polling frequency is fine.
Test your connection
The quickest end-to-end check — a 200 with a JSON body means your key works:
cURL
curl -H "Authorization: Bearer $TOKEN" \
"https://averase.com/api/v1/assets"
A 401 means the key is missing or invalid; see Authentication.