Base URL: https://api.roofquery.com. Authenticate with Authorization: Bearer <your key> — except the file routes (report and storm report files), which take no key.
Copies this whole page as Markdown, so you can paste it into an assistant and have it write the integration. Nothing secret goes on the clipboard — your keys aren't included.
| Value | Terminal | Meaning |
|---|---|---|
processing | No | Accepted and queued for measurement. First status you'll see. |
in-progress | No | A technician is measuring the property. |
on-hold | No | Paused while something about the property is clarified. Resumes on its own. |
completed | Yes | XML available, measurements populated, files listed. |
updated | — | Event only, never a stored status. A completed report received new geometry; status stays completed. Re-download to pick it up. |
cancelled | No | Reviewed and ended without delivery — obstructed imagery, a property that isn't there, a roof that can't be measured. The cost was refunded as account credit, and reason says why. This is the only failure that is about the address. Not terminal: a cancelled order can occasionally still be delivered, and then moves to completed. |
revisions_requested | No | A revision is open. The previously delivered files stay available. |
revision_completed | — | Event only, never a stored status. The corrected report has been re-delivered and status is back to completed. Re-download to pick it up. |
Insufficient balance and refusals are not statuses — they come back as a
402/502 from the order call before an order exists, so there's nothing to webhook
about. status is always one of the six stored values; updated and
revision_completed only ever arrive as a webhook's event.
statusDetail.code on /status
is the stored status, with terminal resolved for you.
A refusal and a cancellation mean different things, and it's worth branching on
that. An order is never refused at placement because the roof can't be
measured — that is only ever established on review, and reaches you as a
cancelled webhook carrying a reason. So a 502
ORDER_FAILED is a problem our end, not a signal to try a different address:
retry it, and tell us if it persists. A cancelled is the one that really
is about the property.
completed twice
The order's status does not change. It is
completed throughout. A delivered report is a completed report,
however many times it is corrected — updated is never a state an order
sits in, only the name of the event announcing one particular delivery. What alternates
is event, and only event:
| What arrived | status | event | previousStatus |
|---|---|---|---|
| First delivery | completed | completed | in-progress |
| Correction — new measurements | completed | updated | completed |
| Correction — new measurements | completed | completed | updated |
| Correction — new measurements | completed | updated | completed |
| Redelivery of an identical document | no webhook at all | ||
It is the same order throughout — same orderId, same entries in
files[]. Nothing is nested and nothing is superseded: the file URLs render
on demand, so they simply start serving the corrected document.
Treat both events the same way: re-download. The two words carry no
different meaning on a redelivery — the alternation exists so no correction is ever
dropped, because a repeated event is otherwise suppressed as a retry. A second
completed carries a reason saying the report was corrected
again. If you only branch on status, you correctly see one thing the whole
time: a completed report.
An identical redelivery is silent on purpose. The document is compared byte for byte, so nothing reaches you unless your measurements actually changed, even when a report is delivered again unchanged.