## Moving to the part blocks (2026-10-08)

If you built against the guide before 2026-10-08, one thing you read has
changed: the checklist item states `not_done` and `unknown`, and their `counts`
keys, are gone, so step 2 is required. Everything else you read is still
there, and the other three steps are worth making:

1. **Read results from `checklist`, not from the completed report.** Drive your
   "verified by RapidEye" state from the `checklist` on
   `inspection.recording_completed`, or from `GET /v1/inspections` once
   `checklist.status` is `complete`. That is seconds after the walk instead of
   hours.
2. **Switch to the new item states (required).** `verified`; `missed` (was
   `not_done`, and now also an item `unknown` because the walkthrough did not
   show it clearly); `explained` (with the cleaner's `reason`); `not_checked`
   (was `unknown` when we could not check the item: not a result about the
   cleaner, so do not count it as missed); and `pending`, which you only see
   while `checklist.status` is `in_progress`; treat it as "checking". A
   "Finish anyway" item now reads `missed`, as it does in the report.
3. **Read the report from `report`.** `report.status` is `ready` exactly when
   the inspection `status` is `completed`, and `report.report_url` is the same
   link as the top-level `report_url`, which stays. While the report is being
   produced, `report.stage` reads `analyzing`.
4. **Take each step's picture from `image_url`** instead of asking the cleaner
   for one, and store the bytes, since the link lives 15 minutes.


## Changelog

| Version | Date | Change |
|---|---|---|
| v1 | 2026-09-18 | Initial release. |
| v1 | 2026-09-19 | **Workspaces switch on by themselves.** A roster import that reaches `applied` now activates every property it lists as `active` and puts the account into service, a few seconds after the import is marked `applied`. The "email us to activate" step is gone. `property_not_activated` and `workspace_not_enabled` still exist but are rare; sending the roster again with a new `Idempotency-Key`, or triggering a sync, clears them. See *Overview*, *Authentication and errors*, *Workspaces*, *Roster* and *Recording links and inspections*. |
| v1 | 2026-09-19 | **Three checklists per home.** The checklist endpoints take an optional `?type=` of `housekeeping` (the default), `inspection` or `maintenance`, and every response echoes `type`. Omitting it behaves exactly as before. See *Home setup*. |
| v1 | 2026-09-19 | **Checklist items carry an `id`.** `GET` and `PUT` return our id for each item, which is what per-item results are keyed on. An id is stable between writes and not across them: a `PUT` issues new ones. See *Home setup*. |
| v1 | 2026-09-19 | **Per-item checklist results.** A `checklist` block with each item's `state` (`verified`, `not_done` or `unknown`) and a `counts` summary, on `GET /v1/inspections` when `completed` and on the findings response. Omitted when the home has no checklist. See *Recording links and inspections*. |
| v1 | 2026-09-19 | **`report_url` on the findings response.** The link to the full report now comes back with the findings, as well as on the status endpoint and the `inspection.completed` webhook. See *Recording links and inspections*. |
| v1 | 2026-09-23 | **Baselines are one set, and removing a tour removes it.** `setup.baseline_photos.count` now counts every photo in the home's baseline, not only the ones your imports and our Google Drive imports added: managers can now add photos themselves (uploads, Drive, their Airbnb listing, Breezeway listing photos). `duplicates` on a photo import now also counts a photo the home already holds from any of those. `DELETE .../matterport` now deletes the tour's imported imagery and stops a running import; before, it only forgot the link and the imagery stayed in use. Sending a different tour replaces the imported one once the new import succeeds. A home runs one import at a time, of any kind: a tour sent while photos import (or photos while a tour imports) answers the other kind's `*_import_in_progress` 409. See *Home setup*. |
| v1 | 2026-10-04 | **No events for a unit that is switched off.** A walkthrough in flight when its unit is switched off in RapidEye still finishes, and its report stays readable from the findings endpoint (and, since the 2026-10-05 row, its video from the video endpoint), but `inspection.recording_completed`, `inspection.completed` and `inspection.failed` are not sent for it. A unit that is off records nothing new, as before. See *What we send back to you*. |
| v1 | 2026-10-05 | **Download the walkthrough video.** New `GET /v1/inspections/{inspection_id}/video` returns a signed download link for the inspection's video, valid 15 minutes, with `expires_at`, `content_type`, `duration_seconds`, `size_bytes` and `recorded_at`. Each call returns a fresh link. The `inspection.completed` webhook now carries `video_url`, the address of that endpoint, which never expires. Two new codes: `409 video_not_ready` and `404 video_not_available`. See *Recording links and inspections* and *Webhooks*. |
| v1 | 2026-10-08 | **Checklist results before the report, and a block per part.** `inspection.recording_completed` now carries the `checklist` block with every item's result: it waits until every item is final and pictured, at most 2 minutes after the walkthrough is sealed, and an item still landing then reads `pending`. Every response and event describes the inspection's two parts as blocks with their own status: `checklist` (`in_progress` or `complete`) and `report` (`processing`, with a `stage` of `analyzing` or `reviewing`, or `ready`, with `report_url`). `GET /v1/inspections` carries `checklist` on every status and `report` on `processing` and `completed`; `inspection.completed` carries both. Item states are now the report's four, `verified`, `missed`, `explained` and `not_checked`, plus `pending` while a verdict is on its way: `not_done` is renamed `missed`; what was `unknown` is `missed` when the walkthrough did not show the item clearly and `not_checked` when we could not check it; a cleaner's explanation is `explained` with their `reason`; and a "Finish anyway" item, which read `verified`, is `missed`, matching the report. `counts` names the five. The status poll signs the pictures afresh on every read. Every item with a result carries `image_url` when we have the picture, a 15-minute signed still from the walkthrough at the moment it was checked off (the picture the report shows), and `timestamp`, so a cleaner no longer needs to photograph each step. `GET /v1/inspections` now carries `inspection_id` from the moment the cleaner opens the link. The `completed` arm's top-level `inspection_id`, `report_url` and `completed_at` are unchanged. See *Per-item checklist results*, *`GET /v1/inspections`* and *What we send back to you*. |
| v1 | 2026-10-09 | **Send the cleaner back to your app.** `GET /v1/recording-link` takes an optional `return_url`, checked against your integration's allowlist (`400 invalid_request` with `detail.parameter: "return_url"` otherwise). Once the walkthrough is sealed, the cleaner's last screen shows for 3 seconds with a **Return to {your name}** button, then navigates to that URL with `inspection_id` and `status=submitted` added. A link requested without it keeps today's last screen. See *Sending the cleaner back to your app*. |
| v1 | 2026-10-14 | **One report stage.** `reviewing` is retired; reports stay in `analyzing` until ready. `report.stage` is `analyzing` for the whole time the report is being produced, then the block reads `ready` with `report_url`. An integration that already treats an unknown stage as in progress needs no change. See *`GET /v1/inspections`*. |

One change alters a shape you may already read: on 2026-10-08 the checklist
item states and their `counts` keys changed. `not_done` and `unknown` are gone
from both, `missed`, `explained`, `not_checked` and `pending` are new, and a "Finish anyway"
item went from `verified` to `missed` (*Moving to the part blocks*, step 2).
Every other new field and parameter is optional or additive, which is why
these sit under `v1` rather than a new version. The other changes in
behaviour are the first row, the 2026-09-23 row, the 2026-10-04 row and the
2026-10-14 row. `service.state`,
`recording_enabled` and `billing_active` now move to on when an import applies,
rather than when we switch them.