Webhooks for the rest of us
This is a salesforce connector that uses the Open Apex Service Specification, in particular:
- the Service Definition inner class
- package agnostic event parameters
- instance configuration via custom setting
What is the "webhook" pattern?
Instead of you polling another system for data... they knock on the door of your system.
What this isn't:
We're not just standing up an Apex webservice class or a REST annotated method. A webhook shouldn't be concerned with performing any action. It should merely eat the notification so the transmitter can "fire and forget."
What it does do:
It separates the three concerns: the synchronous responder that says "got it!"; the event that is persisted; another service performs some action while having no knowledge of the webhook transport.
Why not just hard code the webhook action?
Rolling that Apex webhook probably won't be the first or the last one we ever build. We separate the event from the action by using a service container. And the action gets free transaction management, free error handling, and context independence. Code less like the left, and more like the right:
How to arrange the services?
- First is your webhook
- Second is your action (using an apex service)
How to configure different endpoints?
On any service instance, click Configure to expose:
- URL path
- HTTP verbs
- Custom response
Our goal is simple: to help you cut down barriers in your business and get value from Salesforce. Every day, we help admins and developers take control into their own hands using the platform. Contact us today - we promise instant access to a full stack team who are really easy to work with.
BigAss are Salesforce and Sencha certified and we like what we do. If you work with us, you will like what we do too. Having released several successful ISV packages underlines that we can offer a depth of knowledge to our clients that rivals that of much bigger consultancies.