Webhook
An HTTP request a service sends to your endpoint when something changes, so your system is told rather than having to keep asking.
A webhook inverts the usual direction of an API call. Instead of your system asking a service whether anything has changed, the service sends an HTTP request to a URL you registered at the moment something does. The subscriber writes an endpoint; the publisher takes on the work of deciding when to call it.
The reason to prefer it is latency rather than efficiency. A system polling every minute is on average thirty seconds behind whatever it is watching, regardless of how fresh the underlying source is - and when the consumer is an autonomous agent acting inside a request, that interval is the entire budget spent waiting. Delivery from a nearby node, as in edge computing, removes what is left.
What makes one usable in production is its guarantees rather than its existence: signed payloads so the receiver can verify origin, a sequence so a gap can be detected rather than silently missed, retries on a documented backoff, and a replay window so an outage on the subscriber's side becomes a catch-up. The payload should carry the resolved change and its provenance, not the raw document it came from.
Evidence that keeps pace with the decision.
Evaluate Nuclir against the systems, markets, and decisions that matter to your organization. The result is current intelligence with the context needed to use it responsibly.