Webhooks are an application feature that will send a message to another application when a certain action occurs. For example, if a new contact is added to Yabber, or perhaps a group of new referrals, Yabber may send a HTTP webhook to a nominated 'endpoint', and the 'request' we send will carry information that can be resolved, mapped, or handled in a certain way by the other server or software. Many are familiar with Zapier, and how the tool might action 'something' on the basis of actions taken somewhere else - it's the webhook that originates from your CRM (or the "Trigger App") that makes the information available on the other service (the "Action App"). Webhooks are reasonably reliable, actioned quickly (near real-time), and allow you to build your own applications.
Webhooks in Yabber are generally two-way, in that we will send information to a nominated URL when an action takes place, but we can also accept incoming webhooks from other services. The latter is a little more complicated because functionality overlaps with the Yabber API, so this article will ignore the incoming requests and only look at the outgoing webhook.
Note: Each webhook has four primary components: a URL endpoint, Body, Header, and Request Method. The immediately notification or 'ping' notifying a remote service is more efficient than regular polling to check for changes. If you're using our API, we prefer you use webhooks for notifications, and then use the supplied data or make a new API request. One of the other features we don't introduce on this page is a facility to act on the information that is returned to us after a Request; the webhook is usually a one-way transaction, although data can be returned by the remote application, and we have the capacity to map the returned information to Yabber as if it were submitted via the API (this is generally reserved for advanced users).
Webhooks come in different types and flavours, with most systems supplying change data only, or a simple notification that includes reference to data that has been added or changed. We send a full package of data with our Request that includes all the information a user supplied - this often negates the need for subsequent requests. Many system also limit webhooks of a certain type (such as new contacts) to a single webhook, whereas we provide for any number of webhooks associated with a single Yabber action.
Creating Webhooks
Many will remember our former webhook system. It was similar to SalesTrekker's basic setup in that we simply supplied a single URL endpoint for system changes. However, this method is unacceptable for many because a Yabber change is often required to be disseminated to more than one location or system. We've vacated the 'typical' webhook methodology by sending a full package of data (rather than just a notification that the change took place), and we altered the system to support multiple webhooks for a single system change.
When creating a webhook you'll first be presented with a screen for a name, description, and endpoint. Selecting the next panel returns fields for optional header key/value and body key/value pairs to be sent in the request (an API Key in the header array, for example, will usually be required by the receiving system). These values are optional.
Pictured: Creating a webhook requires you provide a name, description, and endpoint (where we send the request). The key value pairs are optionally and usually determined by the receiving system requirements. It's expected that you will include a field in the body to indicate the type of updating taking place (such as 'referrals' or 'leads' (rather than use our own cryptic 'action' values). You may also update the URL with parameters if required. All data sent with the request is determined by the system calling the webhook. When editing webhooks via the Review panel, you will be presented with all data (skipping the intermediate form step).
To assign a webhook to an action, you'll normally be presented with an option when assigning whatever form automation might apply. Having just introduced the revised mortgage broker referral form, we'll look at how to add a webhook when new referrals are submitted to your website.
Pictured: The mortgage broker referral form automation schedule. Specific automation applies by default when a new referral is received, such as emails to the potential leads, SMS messages to the potential leads, and a notification email to the broker. At the bottom of the panel is an option to send a webhook, and this should be actioned to send the referral package to the defined endpoint. FYI, in the pictured example, each email 'template' is made up of a from email, title, email body, signature, and disclaimer - the template makes it easier to send routine 'admin' messages.
You will note that the panel provisions for the incoming website and partner ID (the latter is an option that may or may not be sent with the form). This gives you more granular control over the conditions that define what webhook will send, and where they will send. As many 'profiles' may be created as necessary for each incoming form submission (subsequent profiles obviously won't include additional client emails).
Pictured: The Lead webhooks are managed via the forms panel, and it includes standard subscription forms (including landing page forms), fact find reports, Venus reports, property SMS forms, event forms, and the system will be updated as new form types are created. No limit is applied to the number of webhooks that will be sent for any single action (meaning that we can notify multiple systems of a change). Most form webhooks, such as those applied to subscription forms, are defined on the basis of form. This move was made because many brokers need different types of notifications for different forms, and different forms are often 'owned' by different brokers.
While a large number of webhook options apply, we still maintain a very basic SalesTrekker-style notification system.
Each module will generally include webhooks within that module, but a summary of all system webhooks is maintained via a link on the Yabber entry page.
A Simple Webhook Endpoint Script
If you're fiddly with PHP and want to play with the data submitted via a webhook, consider the very basic code below.
First, at the top of your PHP page, you'll want to include a http_response_code(200) message. Yabber requires a successful 200 or 201 header response. To get all the headers sent in your request, use <getallheaders(), and to get the payload data, use file_get_contents('php://input') (you'll want to use json_decode($data, true) to decode the data, and then, perhaps, file_put_contents() in order to review the request arrays in plain text. While not production worthy in any way whatsoever, the following block of code is a basic way to write the webhook data to a file.
with the entire webhook payload in plain text. In reality, you probably won't build your own applications, but rather send the webhook to an existing application to be handled on their end.
Endpoint: You will copy the above code into a file called something like 'endpoint.php', and then upload it to a discreet directory on a domain (you'll want to delete it after playing with it - there's no validation so it'll become a publicly accessible URL). The location of this file becomes your 'endpoint'.
Returned Data: After a webhook is sent, the receiving application may send data back to Yabber, and this data is recorded and evaluated. Reserved for advanced users, the data sent back may be mapped on our end to action additional tasks.
Integrations: There are times where a client might have a custom CRM or proprietary internal application that prevents us from building in 'global' default features, and it's in these cases where we might build a simple webhook tool to keep their custom CRM systems up-to-date in real time.
Encryption: Data transported over the web is never entirely secure - regardless of any precautions. Not unlike our standard forms (with a body that is encrypted by default to meet finance standards), we provide an option to send encrypted data, with the package decrypted by way of your API key (your API key isn't exposed in the header or body, but you will still need to provide a header value to verify requests). This is an advanced feature that isn't supported by third-party application, so it may only be used when building your own tools.
Some time back we provided a short course on using PHP and SQL to query financial related data. It's expected that this helpful course will makes its way back into Yabber soon. Having the ability to retrieve data from any source then turn it into something usable in seconds is like a broker superpower.
Conclusion
The most common use for webhooks is lead notifications, although it is rarely required because Yabber provides significant automation by default. However, the hook may be used to feed CRM systems that we don't support, or it may be used to feed an alternate email service - there's really no limit to what you might do with the payload.
Yabber APIs: Yabber provides a large number of APIs for various types of data. Other than primary Yabber data, some APIs will graphs, others RBA and inflation data, and others lender data. The forthcoming property module also includes an open API, and the comparison tools are built on top of an API that is available to all users. Most API features are unpublished, so if you require information, please make contact with us.
Yabber provides a number of APIs that handles data sent to the platform, and it also sends responses to designated endpoints in the same way as webhooks... but it's a different system that is upline to webhooks. A webhook may carry an ID of some kind, and the presence of that ID may give your receiving application reason to query the API for more information. The webhook and APIs are complicated systems, but simply knowing that the systems are there should give you confidence that Yabber will support just about whatever requirement you throw at it.
The tools Yabber provides gives you complete control over your automation and lead-generation strategies. Give us a call if you're interested in the most powerful mortgage broker systems in the industry.
shows the building on the west side of King William Street in 1895 (a single decker horse tram trundles past horse cabs standing in the centre of the street). he E S&A building is in the centre, with the AMP building on the left. On the right is the premises of Robert A. Thompson & Company, Photographers. The extreme right of the photo is 22 yards south of North Terrace. The buildings are long gone (a Westpac branch is on the corner of King William and North Terrace, and a China Bank branch occupies the approximate locating of the old ESA building. [ View Image ]
