Skip to main content
Prophia data is not just uploaded, it is curated. Between a document landing in the system and its terms being trustworthy sit an AI extraction pass and a human review by Prophia’s team. Onboarding is that arc, and several status fields report where a given asset sits on it. If you are mirroring Prophia into a warehouse, this is the page that tells you what to gate on.

The arc

Steps 1–3 are yours: they map onto the onboarding wizard in the app, and onto POST calls in this API if you have write access. Steps 4–6 are Prophia’s, and none of the status fields they drive are writable over REST. Onboarding is not one-and-done. Every new document added to a live building runs through the same extraction-and-curation loop, so documentStatus matters long after a building is handed off.

Document status: the atom

Everything else rolls up from here. A document normally goes processing → incomplete → any account-specific review states configured on your account → complete. Only complete means the data has been curated and signed off — every other value, built-in or account-specific, means it hasn’t. See Documents for the full table.

Lease rollup: docCompletionStatus

A lease’s docCompletionStatus is complete when every document on it is complete, and incomplete otherwise. One un-curated amendment holds the whole lease at incomplete — which is the point: a lease whose latest amendment hasn’t been read yet is not a lease you want to report on.

Building rollup: onboardingStatus

onboardingStatus tracks how far the building has moved through the process. It is read-only over this API.
The middle two values are driven by the app, not the API. INITIAL_SETUP and ONBOARDING_IN_PROGRESS advance when someone works through the onboarding wizard in the UI and marks those steps done. Nothing in the REST API advances them, so a building created and populated purely over the API will likely sit at NOT_STARTED until it flips straight to ONBOARDING_COMPLETE — and even that path isn’t guaranteed. Don’t read NOT_STARTED on an API-driven building as “nothing here yet.”
ONBOARDING_COMPLETE is set automatically, and it happens once in a building’s lifetime. The system flips it when the building is not INACTIVE and every lease in it has finished document curation; the moment it flips, onboardingCompleteDate is stamped. It does not revert when a new document is later uploaded — a live building taking on a new amendment stays ONBOARDING_COMPLETE while that amendment works through the pipeline.
That last point matters: onboardingStatus answers “did this building ever finish its initial onboarding?”, not “is this building’s data current right now.” For the current question, roll up docCompletionStatus across the building’s leases yourself. The progression is also one-way in practice — a building at ONBOARDING_IN_PROGRESS or ONBOARDING_COMPLETE cannot be pushed back to INITIAL_SETUP or NOT_STARTED.

Building state: activeStatus

activeStatus is a different axis: it tracks the building record’s operational state and the internal review checkpoints, and it is also read-only over this API.
AI_PROCESSED means “everything uploaded so far has been machine-tagged”, not “everything has been uploaded.” Documents are frequently supplied across several sessions, so a building can reach AI_PROCESSED while more of its documents are still to come. Treat it as a checkpoint on the building’s current contents rather than a statement that the building is fully loaded.
activeStatus: ACTIVE is the handoff signal, and it is the one worth building on. onboardingStatus: ONBOARDING_COMPLETE says the documents finished processing; ACTIVE says Prophia’s team is satisfied with the result and has released the asset.
implementationManager on the building names the Prophia person responsible for that onboarding and review. It is not the account manager.

What lags during onboarding

Some building fields are caches rebuilt from the stacking plan rather than computed per request, so they can be stale while leases are still in onboarding: totalRentableSquareFootage, squareFootageLeased, squareFootageOccupied, squareFootageVacant Each carries this caveat on the building endpoint. Don’t use them for point-in-time occupancy on a building that isn’t ACTIVE yet.

Putting it together for a sync job

1

Decide your bar

For reporting you can stand behind, filter buildings on activeStatus=ACTIVE and leases on docCompletionStatus: "complete". For a fuller mirror, take everything and carry the status fields through so downstream consumers can decide.
2

Poll for change, don't re-crawl

GET .../recent_changed_leases names the leases whose documents changed in a window. That covers both new documents arriving and existing ones reaching complete.
3

Re-check status on every pass

A lease that was incomplete last week may be complete now, with different tag values. Curation corrects machine extraction — treat pre-complete values as provisional and expect them to change.