What to require from your property management platform’s API

Most property management platforms handle their own data well. The problem starts when that data needs to move somewhere else, into an accounting system, a tenant platform, a BMS or a maintenance tool that the operations team already uses.

An API is what makes that movement possible without manual handling. Instead of exporting a file, opening another system and importing it again, the data flows automatically between platforms. The result is less manual work and fewer places where information can go wrong.

For a property manager, the practical question is not what an API is. It is what happens when the platform does not have one, or when it does but it is closed.

Three everyday tasks that disappear with an integration

Work orders from BMS alarms. When a sensor triggers an alarm in the building management system, someone has to log that as a work order. With an integration, that step happens automatically, the alarm creates a work order in the right system, linked to the right asset and location.

Component data from BIM. When a building is modelled and asset data exists in a BIM tool, that data should not have to be re-entered manually into the property management platform. An integration moves it once and keeps it in sync.

Fault reports from tenant platforms. When a tenant submits a fault report through an external form or portal, that report should land directly in the work order system, with location, asset and priority already attached. Without an integration, someone reads the email and types it in again.

Vyer integrates with a range of systems used in property management, including Vitec Hyra, Q3-web and Kiwa, so that information from property administration, inspections and certifications flows directly into the platform without manual re-entry.

What to require from your platform

An open API. A closed API means the vendor controls which integrations exist and which do not. An open API means you can connect the systems you already use, or build new connections as your needs change.

Documentation. An API without documentation is an API that no one can use without paying the vendor to build it for them. Ask to see the documentation before signing a contract.

Permission controls. Integrations should only access the data they need. Ask how permissions are structured and whether you can restrict access per integration.

Questions to ask your vendor

• Do you have an open API with public documentation?

• Which integrations exist today and which are on the roadmap?

• Who builds and maintains integrations — you or the vendor?

• What happens to our data and our integrations if we leave?