Base URL: https://api.roofquery.com. Authenticate with Authorization: Bearer <your key> — except the four file routes, 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. |
revisions_requested | No | A revision is open. The previously delivered files stay available. |
revision_completed | Yes | The corrected report has been re-delivered. |
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. The same eight values appear as statusDetail.code, 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 two 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 — the provider does sometimes resend a file unchanged.