How UniAsset protects your data
In transit
HTTPS everywhere. In production, browsers are instructed to use HTTPS for two years, including on subdomains.
Webhooks must target HTTPS. Plain HTTP endpoints are rejected when you configure a webhook, and every delivery is signed so your endpoint can verify it came from UniAsset and was not altered on the way. See Verifying webhook signatures.
Passwords
Passwords are hashed, never stored in readable form. They are never logged and never emailed.
Password reset issues a single-use token with an expiry, verified before any change is applied.
API keys
An API key is shown once, at creation. UniAsset stores only a short lookup prefix and a hash — the key itself cannot be retrieved afterwards, by anyone.
If you lose it, revoke it and create a new one. There is no recovery path, by design.
Keys can be restricted to specific IP addresses, and revocation is immediate.
Files
Documents, images, and work order photos are stored in cloud blob storage, with each file held under a per-organization prefix.
That prefix is what makes ownership unambiguous in storage — and it is what allows erasure to sweep an organization's entire storage and guarantee nothing survives when the organization is deleted.
The low-level operations that enumerate and bulk-delete files are deliberately kept off the surface a browser can reach, so they cannot be invoked from client code.
Your browser session
Every page carries a full set of security headers, including a content security policy that restricts what can run and where data can be sent. It is the primary defence against script injection, clickjacking, and exfiltration.
Violations are reported to an internal endpoint.
Secrets
Payment credentials, API keys, and provider secrets stay server-side. Modules that must never reach a browser are marked as such, so an accidental import is a build failure rather than a leak.
Errors
Raw errors, connection strings, and infrastructure detail are never shown to users. The only technical detail displayed is an opaque reference code — which is also written to the logs, so a reported failure can be traced without exposing anything.
Request bodies are sanitised before being written to the integration audit log.
What you control
- Use a unique password, or sign in with Google or Microsoft
- Give each integration its own API key with the minimum scopes
- Restrict keys by IP where the calling system has a fixed address
- Revoke keys when a system is decommissioned or someone leaves
- Store keys in a secret manager, never in source control or client-side code
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support