Skip to main content
Everything in the Prophia API is scoped to an account, and underneath the account run two parallel spines:
  • the physical spine — Property → Building → BuildingSpace — describes real estate you own or manage
  • the contractual spine — Lease → LeaseDoc → DocTag — describes the agreements occupying it
The two spines meet at the building: every lease belongs to a building (and through it, a property). The solid path down the middle is the id-linked spine: every resource carries the ids of its ancestors (accountId, propertyId, buildingId, leaseId, leaseDocId), so you can walk it in either direction. The dashed links are the two side relationships — spaces hanging off the building, and subleases hanging off a lease — plus the one association that is a name match rather than a foreign key.

The entities

Most resources also embed a url that deep-links into the Prophia web app.
A tag’s applicableSpaces[].name refers to a BuildingSpace by suite name, not by id. There is no foreign key: match applicableSpaces[].name against BuildingSpace.suiteNumber within the same buildingId. Renaming a suite silently breaks the association, and the sentinel names "Entire building" and "All spaces" never correspond to a real space record.
This is the one relationship in the diagram that is a name match rather than an id reference — the dashed line on the right. See Spaces, applicable spaces, and encumbrances for the matching rules and a worked recipe.

Absent means “not requested”

One convention is worth stating once, because it applies to every response: the API omits null fields entirely. A field populated by an include you didn’t request is simply missing from the JSON. Branch on presence, not on emptiness — a missing tags key means “not requested”, never “no tags”. An empty array means you asked and there were none. Everything else — which fields exist, what type each one is, what its values mean — is documented per field on the endpoint pages, and those are authoritative.