A webhook is a way for one system to notify another the moment something happens: instead of the second system repeatedly asking whether anything new exists, it registers a URL once and the first system sends it a message automatically when a chosen event occurs.
GitHub’s developer documentation gives the clearest plain description of the mechanism, in one continuous passage describing its own feature: “Webhooks let you subscribe to events happening in a software system and automatically receive a delivery of data to your server whenever those events occur. Webhooks are used to receive data as it happens, as opposed to polling an API… to see if data is available”. An AI system wired to act the moment a form is submitted or a payment clears is almost always sitting behind a webhook rather than checking on a timer.
A webhook that carries a Canadian customer’s personal information to an AI vendor is still a transfer for processing under PIPEDA, and accountability does not move with the data. Schedule 1’s clause 4.1.3 is explicit, in full: “An organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing. The organization shall use contractual or other means to provide a comparable level of protection while the information is being processed by a third party”. Firing a webhook to a vendor’s endpoint doesn’t change who is accountable if that vendor mishandles what arrives.
A CRM can either poll a payment processor every five minutes asking “anything new?”, or it can register a webhook once and let the payment processor push a message the instant a payment clears. The second approach is faster and lighter on both systems, because nothing has to keep asking.
See also: what is an API, what is robotic process automation, what an integration does, in plain terms.
Wiring a webhook to trigger an AI system safely — and deciding what it’s allowed to do when it fires — is ai-integration-automation’s job.
