I talked to someone at a co-working space in Lafayette who was a member of a company there and they were working on a similar project. I can't for the life of me remember anything else about it though.
1. Docs for webhooks are located in our app (after login). But a basic outline is that you add your URL, add any custom headers you wish, get the signing key, subscribe to an event and you're off the races. Events that we currently support are Job Success, Job Failure, New Data, Diff Data. Probably the most popular event (as you have alluded to in your next question) is our Diff Data event. The payload for this event will return only the data that has changed for a particular record since the last time we received data from a PMS.
2. Currently, not via the API. We will be adding more features like this to the API in the coming weeks. For now, our customers seem to prefer the Diff Data webhook anyway.
3. We do cache the data. One of the hallmarks of PMS APIs is that they are unreliable. That being the case, all of the data served from our API is from our cache so we can pass along our uptime SLA benefits to our customers.
Thank you for responding so promptly! That seems quite interesting :).
Diff data + new data definitely seem what 90% of your customers will need.
Another quick question: When you say "Job Success/Failure", what's a job?
_Full disclosure: I work at LeadSimple <https://www.leadsimple.com> and we integrate with most of these companies ourselves, and these questions were just me being interested in knowing how you solved (or intend to solve) some of the same problems we had to solve when integrating with them :)_
Of course, since we are not a pass-through API, our tech is set up as an async ETL. So a job represents a unit of work for Propify either fetching data from or pushing data to a PMS. You can track jobs to understand the lifecycle of your requests and overall status of your integrations.
Oh, got it, because you'll save any POST/PATCH request and try updating it in the PMS in case they've been down. That's cool, thank you for clarifying that :)
Ben said he's talking to you all next week! Looking forward to it.
Our current integrations include Yardi, RealPage, Entrata, Propertyware, Buildium, Rent Manager and Rentvine. On the roadmap are Appfolio, MRI and ResMan.
Propertyware does charge an access fee, you are correct. Additionally, they offer a licensing agreement where their customers can provide API keys to consultants to help them build out their tool(s). We are one of those consultants.
As far as who assumes the access fees, they are managed strictly by our customers and we have no pass-through pricing on that side. Our pricing is solely based on our own costs, infra, value, etc. All of our customers get access to all of our integrations (current and future) as part of our standard pricing model.
Totally agree! This is part of the conversation with each of our customers. We have learned early that this is a part of the pain and we are solving it in two ways:
1. Rapidly developing a deep understanding for naming and meaning within each PMS so we can speak intelligently, and properly guide our customers to focus on the data they care about.
2. Technically, we have data transformations at a couple different layers so we can repoint data coming in to exist in customer-specific locations for their business needs.
Thanks for your feedback! Unfortunately your story is a common one - not much has changed with these APIs since 2012... or since 1999 for that matter.
Our current integrations include Yardi, RealPage, Entrata, Propertyware, Buildium, Rent Manager and Rentvine. On the roadmap are Appfolio, MRI and ResMan.
Necessary disclaimer: we only support integrations for customers who have officially sanctioned relationships with each PMS. We do not do anything that violates ToS (e.g. scraping, chrome extensions, etc.).
From my memory some of the big players require api license fees in the thousands per api. It was my understanding that these are to be paid by every implementor using their docs. How are you guys getting API access to build? Is this not really as common anymore?
Some of the systems remain pay-to-play for sure. We have adopted the consultant model where we are implementing our solution on behalf of our customers. This is why we require our customers to have their own relationship with each PMS. Their credentials are used to access each API. I sent a connect request to you on LI - happy to chat in more detail!
