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.
Reports carry your brand, or your customer's. Set a company name and the header, footer, cover-page attribution and legal contact block all become that company's; a small RoofQuery watermark remains in the footer. Leave the name blank and the report falls back to full RoofQuery branding. The XML carries no branding at all.
The brand is chosen when you order, and the order keeps it.
| Brand | Set where | Answers |
|---|---|---|
| Account defaults | Portal, Branding → Defaults | "What does my own report look like?" Your brand, license # and logo. Every order placed without a brand. |
| Brand profile | /branding/profiles, or Branding → Profiles | "What does this contractor's report look like?" One saved brand per contractor, logo included, named as brand when placing the order. |
A download can't change an order's brand: every PDF of it carries the brand it was ordered with. A profile is complete — nothing falls through to your defaults — because a half-applied brand prints one company's name over another company's phone number.
# An order for a contractor: its PDF carries Acme Roofing, logo included, on every download
curl -X POST "https://api.roofquery.com/api/v1/reports/orders" \
-H "Authorization: Bearer rq_live_sk_..." -H "Content-Type: application/json" \
-d '{ ..., "brand": "rq_brand_7f3a21c9d4e07b16" }'
Orders placed before 22 October 2026 keep the old rule: a download picks the
brand, with ?brand=<profileId> or per-download params (name, contact block
and colours for one file; most specific wins: params over profile over defaults). See
PDF.
Your own defaults are configured once, by a person who can see the result — whether a colour reads against white, how a wordmark sits in the header. A preview answers that; an endpoint doesn't. Profiles are the opposite case: a platform with two hundred contractors is not going to click through two hundred forms, and the id has to end up on a contractor record in your database, to send with each order. So profiles are an API first and a portal tab second.
There is no field anywhere that takes a URL, and that's deliberate. A linked logo is
somebody else's uptime — a report that renders today comes back logo-less the day their
site moves — and it would mean this API fetching an arbitrary address on your say-so.
Upload the bytes once, to your account or to a profile, and they're ours to serve.
That is also why there is no ?logo= param: a URL is exactly what a logo
must never be.
Every logo is placed on a square canvas automatically. The report header gives the logo a 1:1 slot, so anything that isn't square would otherwise be letterboxed or centre-cropped at render time. Upload whatever shape you have — a wide wordmark, a tall badge, a favicon — and it's scaled to fit and padded with transparency to a 512×512 PNG. Nothing is ever cropped: your proportions are kept exactly, and the padding disappears into the header band. Small logos are scaled up to fill the canvas, so a 64px icon doesn't render as a speck.
Nothing is cached — the PDF is rendered at the moment you request it. Change your defaults or a profile and the reports ordered with them come back updated on their next download.