Last Updated on September 9, 2022 by Rakesh Gupta
What is a Webhook?
Whenever two separate systems are connected, they can communicate with each other through the internet by sending and receiving messages. One of the systems can be the receiving system and the other the sending system, but sometimes they can switch roles depending on the integration. The receiving system exposes what we call an API (Application Programming Interface), which consists of a list of endpoints, each expecting a different type of message.
The messages usually consist of an address where the receiving system lives (URL), a method that determines what the sending system intends to do with the data (GET, POST, DELETE, etc), and then the body of the message itself. The body of the message that is sent has a format specific to that endpoint. If the receiving system receives what it expects and all goes well, it returns a response message, which consists of a response code (i.e, 200 = success, 400 = bad request, 500 = server error, etc) and a response body. This is what we call a webhook.
The REST APIs usually use the JSON format to exchange messages. The JSON format is a data exchange format that makes it simple for both humans and machines to read and write data.
How can you build Webhooks in Salesforce?
Salesforce can be both at the sending side and receiving side of an integration. Salesforce already has a REST API to extract and manipulate data, so it can act as a basic receiving system. Out of the box, Salesforce can also act as a sending system where you can declaratively send very simple messages to other APIs.
Things get complicated when you want to integrate with more complex REST APIs. The options you have out there have a few drawbacks. Let’s explore the options.
Apex
One common option is to build the integration from scratch using Apex, Salesforce’s backend programming language. Using Apex, you can implement outbound calls as well as inbound endpoints, so your org can act as both the sending and receiving system. You can use the HttpRequest class to build outbound calls to an external REST API. Then you can use RestResource to create an endpoint where an external system can send messages.
Implementing the integration in Apex can provide you with a lot of flexibility in the integration needs and, if done right, a very stable integration.
Unfortunately, it also has some drawbacks. First, it requires Apex programming skills. With the developer scarcity in the ecosystem, this becomes an expensive option to integrate with a custom REST API. Another drawback is that, if not done right, the integration can become unreliable and pretty hard to debug. Also, the solution can be hard to maintain since, in order to make a change, you need to create a sandbox, make the change there and then deploy the changes to production.
Middleware
Another option to integrate 2 systems is to use a middleware integration application, like Zapier or Workato. Applications like these don’t live on any of the systems but instead can connect to both systems through API and sync records.
In order to be able to use a middleware, both systems need to expose an API. So both systems will act as a receiving system for the middleware. Furthermore, the middleware needs pre-defined connectors to connect to each system. They usually have connectors for commonly used APIs like Salesforce or Google, but proprietary or less popular REST APIs don’t, so you cannot easily connect to them using this.
The middleware integrations can make it hard to react to real-time data changes in order to sync data between systems. It can also get pretty expensive.
Declarative Webhooks
Wouldn’t it be great if we can implement an integration that:
- Does not require code
- Is easy to update even without a sandbox
- Is reliable and robust
- Is flexible and allows you to use any JSON based REST API
- Can it be declaratively embedded in your business process?
- Is secure and native to the Salesforce platform
That’s where Declarative Webhooks comes in!
Omnitoria spent many years building integration after integration for their clients! It was time to use the experience to put the power and flexibility in the hands of Salesforce administrators!
How can Declarative Webhooks help you integrate Salesforce with external APIs?
Declarative Webhooks is an application that lives in Salesforce. It helps you connect to any REST API, regardless if it’s a private API, or how popular it is, and you don’t need a developer! With a bit of JSON knowledge and the documentation of the API, you can create and use outbound calls and inbound webhook listeners. With Declarative Webhooks, you can be both on the sending and receiving side of an integration.
Outbound calls
In order to make callouts to an external API, Declarative Webhooks uses Callout Templates. A Callout Template is the model of a call. When you edit a Callout Template, you can define the message details: The URL, the method, the authentication details, headers and the JSON Body. For all of these details, you can define field mapping from your Salesforce objects.
The powerful JSON Builder interface makes it easy to define JSON nodes, map fields into them, define formulas based on fields, etc. It allows you to define JSON of virtually any complexity and map fields from related objects, related lists, etc.
After defining the call details, you can define what actions you’d like to take. You can update the record you started from, create and update related records, etc. You can then test a callout template from the built-in test page.
After defining, testing and activating a Callout Template, you can call it automatically from a flow, process builder, a custom button on a page layout, you can schedule it to run regularly and you can even initiate it with Apex.
All calls that are made, either from the test page or any implementation, are logged. You can see a history of all the calls that were made, with all the message details, as well as the response code and response body, to easily debug any integration issues.
When you define a Callout Template, you can also set up a retry strategy. You can set a template to retry a call up to 5 times, at customizable intervals. All calls that are made automatically from Flows, Process Builder or scheduled jobs will be retried automatically if the call failed and the retry is set up.
Inbound calls
With Declarative Webhooks, Salesforce can also act as the receiving system with Inbound Call Templates.
Similar to Callout Templates, when you define an Inbound Call Template, you have the option to choose what actions to take when an inbound call comes in, as well as the response to send back to the caller. You can make the template public (if you want anyone with the link to be able to send calls) or private (only authenticated systems can make calls).
Similar to the outbound call, the JSON Builder interface helps you to define the JSON response of any complexity and map fields into it.
Once activated, the template will act upon any inbound call that comes to its defined URL. You can verify the activity in the call logs. You can see what the request was and how the template responded.
Callout sequences
When you have to send multiple calls one after another, you can use callout sequences. For example, you need to integrate with multiple systems based on one record update, or you want to send data to two different endpoints. You can define what calls to make in a sequence and what criteria to use to decide when to make one call or another.
Conclusion
So you need to integrate Salesforce with another system. You want a flexible yet robust Salesforce solution that you can configure yourself and won’t break your bank. There is no better way to achieve that than Declarative Webhooks!
Formative Assessment:
I want to hear from you!
What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.
