Integrations
Proof that lands in your system, not in your inbox
A certificate of data destruction is worth nothing if the person auditing that device cannot find it. The device record and its Data Destruction Certificate are written into the asset or service management system you already run, so the evidence sits against the asset instead of in a folder somebody has to remember.
What the interface will not do
An evidence record that cannot be edited or deleted
The rest of this page describes what the API does. This part describes what it refuses to do, and it is the part that matters.
Asset records, asset groups, files and sanitisation records cannot be deleted through the platform interface. Sanitisation records cannot be modified. Ownership cannot be transferred.
A mistake is not corrected by editing the record. The entry is marked, a note explains why, and a new record is created alongside it. History is added to, never rewritten.
An evidence store that can be quietly emptied through its own interface is a reporting system.
That is a deliberate constraint, not a missing feature. The difference between the two only shows up at the moment somebody needs a record and it is not there.
What moves
One record per device, carried through to your system of record
A record is created for each device as it is processed, holding the type, make, model, serial and asset number. Where destruction is proven, the certificate is generated and pushed to the platform, and your system attaches it to the matching asset.
The certificate is issued and written against the asset in your own system, with the standard applied, the operation actually executed on that unit, the result and the timings. Files carry a checksum, so the certificate you hold can be verified as the certificate that was issued.
No certificate exists, so nothing arrives in your records claiming a destruction that did not happen. The device is quarantined, and your system shows it as unresolved rather than closed.
The sanitisation record is structured data rather than a document. Your system holds the evidence, not a picture of it.
Two routes
A documented API, or a published export where a live connection is not possible
Certificates can be delivered as a direct download or encoded inside the response, because not every service management platform can take a file the same way. When a customer platform could not accept a direct download, we changed the product to fit rather than asking them to change their platform, and encoded delivery has been standard since.
Verification
Anyone in the chain can check a device without an account
Scan
Every device processed carries a unique QR label linked to its own record.
Read
The make, model, serial and capacity, the standard applied and the result. An auditor can pick up a machine in a cupboard two years later and read its history off the label.
No login
Nobody in the chain needs an account with us, and nobody needs to ask us.
Evidence that only the supplier who created it can produce is worth less than evidence anybody can check.
Start here
Three ways to start
See the documentation. We send the OpenAPI specification and the integration guidelines. No form, no call first.
Get a sandbox. Your own environment and a test key, so your team can build and test before anything touches production.
Talk to the engineers who have done it, not an account manager.