title: Should you use webhooks in an enterprise on-prem application?
body: <p>We produce an enterprise DLT (Blockchain) application for big banks, FMIs, exchanges etc..</p>
  <p>Being distributed each instance of the application is installed on-prem for each customer, as they must remain the sovereign owner of their private keys.</p>
  <p>We want to integrate with a SaaS application that is widely used in the banking sector. We intend to achieve this by writing a &quot;connector&quot; which will also run on-prem and be able to communicate and marshal data between the SaaS system and our on-prem system.</p>
  <p>Events occur in the SaaS app, which must then trigger something to happen in our on-prem app.</p>
  <p>The SaaS app has a RESTful API as well as webhooks. So there are 2 options in my eyes:</p>
  <ul>
  <li>Poll the RESTful API
  <ul>
  <li>Con: This is inefficient as most traffic will simply be &quot;any new events?&quot; &quot;no&quot;</li>
  <li>Con: There will be some latency between the event occurring on the SaaS system and our on-prem app being triggered</li>
  <li>Pro: This is stable. If the connector (the thing doing the polling) goes down, it will pick up any missed &quot;events&quot; from the SaaS system when it comes back up and process them</li>
  <li>Pro: There is no requirement to allow internet traffic into the firewall - the comms are all outbound.</li>
  </ul>
  </li>
  <li>Use the webhooks
  <ul>
  <li>Pro: Very efficient</li>
  <li>Pro: Get events in near real-time</li>
  <li>Con: What happens if the connector is down and we miss a webhook? Does the SaaS system need a retry mechanism? We need to ensure that we only process messages exactly once. (this is important because the action we perform moves large amounts of funds so double processing would be extremely bad!)</li>
  <li>Con: The bank would need to punch a hole in the firewall to allow the SaaS app to communicate into the connector - the bank's security teams won't like this IMO.</li>
  </ul>
  </li>
  </ul>
  <p>Is there a common, enterprise ready, security policy friendly way to do deal with this?</p>