Information regarding Webdadi's APIs

Owned by Elliott
Aug 30, 2023
3 min read

Webdadi has an API feature designed to allow third party products, software and portals to access property, contact or blogging data stored in VIA.

A separate API key is required for the following three entities:

  1. Property information - an XML pull feed requiring an API key. The XML is paginated, but the total number of pages is listed in the summary at the top of the page

  2. Contact information - an XML pull feed requiring an API key. The XML is paginated, but the total number of pages is listed in the summary at the top of the page

  3. Blog Posts - an RSS 2.0 pull feed not requiring an API Key (publically accessible).

The purpose behind these API driven feeds is and is not limited to;

a) for properties to allow for non-standard portal feeds as required such as On The Market pre-market new instructions before the properties are approved and sent to RightMove and Zoopla.

b) for contacts, 3rd party systems such as rent collections like PayProp and others who wish to work with our CRM data and on the basis we allow our customers to do that, we are enabling them to allow 3rd parties to pull the data on a capped view/request basis.

c) for blog posts to allow social media manager tools such as Metricool or Hootsuite, to be able to pickup the feed so that social posts can be automatically published to multi channels on a timed release basis as and when new blog posts are created. Metricool allows this in the form of autolists. HootSuite allows this as an RSS feed via an in-app purchase to Synapfeeds.

d) for full Data Extractions and Backups to be used by 3rd Parties.

 

 

The Limits

The feed system caches (saves the xml or rss feed as a file) on the server which is then served for each API request made, rather than the feed having to directly query the database, and then return fresh results each time, thus this caching solution reduces our database server load.

The server RSS/XML file caching is now for a total of 30 mins after which any new API request thereafter (A view) will automatically replace the cached RSS feed file on our server. The user’s internet browser grabbing the feed will itself also cache the RSS feed in its own browser file cache storage for a total of 30 minutes at a time.

The browser will be able to refresh the feed data after 30 minutes pass, and will then receive the latest file version, that is the RSS/XML feed as a file on the server that has been cached by the API process. If there is no file the browser or RSS/XML feed app making the request will simply make a request that will in turn directly make the request from the DB which will create the initial file from which it will then be served from cache.

If a 3rd-party supplier wants to, or does use the API to try and pull data more often than this on any day and in any given period in the day, they will only at the moment get the file that is effectively up to 30 minutes old. The API requests can be made 7 days per week.