Inspecta developer documentation
Inspecta collects described, photographed mold inquiries from your own website and turns each one into a written assessment. This section covers the three ways it connects to everything else you run: the embeddable widget, hosted assessment links, and webhooks to your own endpoint.
Everything documented here is behaviour that ships today. Where something has a limit or does not exist, that is written down too.
What you can integrate
Three surfaces are supported, and they are meant to be used together. The widget collects the inquiry, the hosted links let you put an assessment anywhere you can put a URL, and webhooks push each lead and finished report into your CRM, inbox or scheduler the moment it exists.
Widget and hosted links
The script tag, how the embedded frame behaves, and the two link formats you can share.
Webhooks
Events, exact payloads, signature verification, retries, delivery history and testing.
Endpoint reference
Every HTTP endpoint the server exposes, generated from the specification it is built against.
Errors, limits and security
The error shape, which routes are rate limited, and the rules applied to webhook targets.
The fastest path from nothing to a working installation is one script tag on the page where homeowners already land.
<script src="https://getinspecta.com/api/embed.js"
data-inspecta-widget="YOUR_WIDGET_ID" async></script>There is no API key, and that is deliberate
Inspecta does not issue API keys, client secrets or bearer tokens, and there is no server-to-server API you can call on your own behalf. Every authenticated route belongs to the dashboard and is authenticated by the signed-in browser session behind it.
Data leaves Inspecta by webhook. If you need a lead or a finished report inside another system, subscribe an endpoint and receive it as it happens, rather than polling for it.
The endpoint reference lists every route the server exposes, because knowing what the product does is useful even when you cannot call most of it directly. Each group there says what actually authenticates it, which ranges from nothing at all to an Inspecta administrator account.
Addresses
- https://getinspecta.com/api
- The API base. Every path in the endpoint reference is relative to it, and the embed loader is served from
/api/embed.js. - https://getinspecta.com/a/{company}/{widget}
- A hosted assessment. Share it in an email, an ad, a QR code or a text message when there is no page to embed on.
- https://getinspecta.com/report/{token}
- A finished assessment, readable by anyone holding the link. The token arrives in both webhook events.
- https://getinspecta.com/settings
- Where webhook endpoints are created, tested and paused.
Conventions
- Requests and responses are JSON, UTF-8, with no envelope around the payload, and errors always take the shape
{"error": "..."}. Two things are not JSON:/embed.js, which is the loader script itself, and the stored object routes, which return the file's own bytes. - Timestamps are ISO 8601 strings in UTC, for example
2026-09-04T15:12:07.884Z. - Identifiers are opaque. Most are UUIDs, webhook event IDs are prefixed with
evt_, signing secrets withwhsec_, and report tokens are random strings. Match on them, do not parse them. - A field that has no value is present and
nullrather than missing, so a receiver can read it without guarding every access. - Monetary amounts are whole US dollars in a
number, alongside an explicitcurrencyfield.
Getting help
If something here does not match what you are seeing, the documentation is the thing to distrust. Write down the event ID or the delivery ID from the header, the timestamp, and what you expected, and send it to support from your dashboard. Never include a signing secret in a support message.