LeaseDoc) is a file attached to a lease — the original lease agreement, an amendment, a work letter, an exhibit. Documents are the raw material for everything Prophia extracts: tags come from documents, and a lease’s data is only as complete as its documents are.
A filename cannot be duplicated within a single lease. Documents can also be filed against a property or a building rather than a lease — rent rolls, stacking plans — and those are reached with include=documents on the property or building.
documentStatus: the curation lifecycle
documentStatus reports how far a document has moved through Prophia’s pipeline and review. It is not a simple binary, and the last step is a human one.
A document normally travels:
That order is the normal path, not an enforced state machine. A reviewer can move a document to any state at any point, so don’t build a client that assumes it will observe each step, or that a document only ever moves forward.The one guarantee to lean on:
documentStatus === "complete" is the whole test for curated. Account-specific status names are validated against the built-in set when they’re created, so a custom state can never be named complete or incomplete — which means any value you don’t recognize is a review state that hasn’t reached the end yet. (If an account-specific status is later deleted, documents sitting on it fall back to incomplete.)documentStatus is typed as a plain string rather than an enum for exactly this reason — the account-specific values are open-ended. processing is also the only value that means “not readable yet”; everything after it is readable, and the question is just how much of it has been reviewed. If you are mirroring Prophia data, complete is the line to gate on.
A lease rolls this up into docCompletionStatus, which applies exactly that test: complete only when every document on the lease is complete, and incomplete when any one of them sits on anything else — a built-in state or an account-specific one. A building rolls the leases up in turn — see Understanding onboarding.
Uploading a document
1
Upload
POST /rest/v2/accounts/{accountId}/docs/upload — a multipart form with file and leaseId required, plus optional filename, title, and docCategory. Or POST .../docs to have Prophia fetch it from a presigned https URL instead.2
Poll
Re-fetch the lease’s documents with
GET .../leases/{leaseId}/docs on a modest interval — pipeline processing takes minutes, so start around 30–60 seconds — until the new document’s documentStatus is no longer processing.3
Read
Once it clears, page geometry (
GET .../docs/{leaseDocId}/pages) and extracted tags (GET .../docs/{leaseDocId}/tags) are available. Remember they are machine-extracted until the document reaches complete.docCategory
docCategory classifies the document — Main Lease Agreement, Extension - Amendment, Rent Roll, Work Letter, and so on. It is filterable on the document list endpoints and it is not cosmetic: some categories determine which tags and in-app features a document participates in.
Leave it blank on create and Prophia’s AI will inspect the document and set it, with human review to follow. The AI will not overwrite a category you set yourself, so supply one when you already know it.
Citations
A tag’s provenance lives on the document. Requestinclude=tagSelections,pages on any tag endpoint and you get the rectangles where each value was captured, plus the geometry of the pages they sit on. See Tags and tag values for the coordinate system.
Change detection for sync jobs
If you mirror Prophia data into a warehouse, don’t re-crawl the whole tree.GET /rest/v2/accounts/{accountId}/recent_changed_leases returns leases whose documents changed inside a start_date–end_date window (inclusive, yyyy-MM-dd) — poll it and re-fetch only what it names. It accepts the same include keys as other lease reads (tags, documents, subleases).
Because the window is keyed on document change, this catches the events that matter most for a mirror: a new amendment landing, and a document moving to complete as curation finishes.