PMS Generic APIs

Read Endpoints

All GET endpoints are generic and will be uniform for all PM systems. There are no system-specific GET endpoints. Since Propexo is a unified API, the data shape will be the same for all systems. What will differ is the completeness of the data returned. For example, Propexo’s response payload will always include a middle_name field, but it may be null for Appfolio, while Yardi provides a value.

Except for a few limited cases, all fields in every response payload are nullable. This is to account for the fact that not all systems will hydrate all fields. There are few core fields which should be have values in every payload, including id, created_at, updated_at, last_seen, integration_id, and integration_vendor. You should assume all other fields may be null in some cases. Please reach out to Propexo for details if you have questions about any field.

Write Endpoints

With the Propexo API, you can choose to leverage our generic write endpoints or the system-specific write endpoints. The benefit to using generic write endpoints is that you do not have to manage many different endpoints that perform the same operation.

Below is an example of what it might look like to write to the generic endpoint creating a lease.
1// Propexo will route the request to the
2// appropriate system-specific endpoint
3// under the hood.
4await app.post('/v1/leases',
5    {
6        ...leasePayload,
7        integration_id: 'foo'
8    })
Below is an example of what it might look like to write to a system-specific endpoint. Note that you would need to understand the system context and define the Entrata specific endpoint.
1// You would need to understand the system context
2// and define the Entrata specific endpoint.
3await app.post('/v1/leases/entrata',
4    {
5        ...leasePayload,
6        integration_id: 'bar'
7    })

The end result will be the same. You are just given the option to choose how much control you would like.