Six tips for a successful Boomi webhook integration
🚩Six tips for a successful Boomi webhook integration
Webhook is one of the convenient and efficient ways to integrate two applications in real-time.
In contrast to polling, where the integration periodically queries the source server to see if new data is available, in webhooks, the source application will transmit the data to the integration endpoint whenever a change occurs in it. This saves resources for the Boomi server.
Most developers default to building scheduled integration to query records based on Last Successful Run Date though the application provides webhook functionality. It is easier to build a webhook integration than a scheduled-based integration as the process logic for schedule-based integration may require to process several documents in a single execution and you must carefully process valid documents and report any invalid documents.
✅Study the API documentation:
Study the API documentation or speak with source application administrators to understand what event types your application supports. Some applications provide partial webhook support such as creation of a record might be available but not update. If the event you’re interested in is NOT available via webhook, you need to query API to retrieve them.
✅Return proper http response code /response:
Most source server expects a specific http response/status code. An XML or JSON response payload with a success status and/or 200/202 response code. Any other response/status code would be considered as a failed delivery by the source server.
✅Return response within expected time limit:
Source application expects response within a specific time limit. If response is not returned within time limit, the source server considers it to be client timeout and marks it as failed delivery.
If your integration involves more processing steps, consider a light-weight process to receive the events, place the message in disk/queue to be asynchronously processed and return a response immediately.
✅Use Process Route component to route events:
When you subscribe to more than one event to a webhook, the Boomi callback endpoint would receive all those events you are interested in. Build separate subprocesses for each event type and leverage process route component so that subprocesses can be deployed independently. This ensures you can deploy only required parts and NOT deploy all the associated components every time.
✅Consider Low Latency Process Mode:
If there are higher volume of events, consider enabling Low Latency Process Mode in process options.
Most source applications expect the callback endpoint to be secured using basic auth when setting up webhook.
Some applications don’t require any authentication in the callback URL. However, as Boomi Shared webserver is basic auth enabled, you can include the base64 encoded basic auth details in boomi_auth parameter in callback endpoint so that Boomi accepts the request.
What other tip would you like to add ❓