Is a webhook different from a push API?

A webhook is a specific way to push information. You register a URL with a service, and when a subscribed event happens, the service sends an HTTP request, often a POST, to that URL. Your system receives the notification instead of repeatedly asking whether anything has changed.

Push API is a broader and less precise term. Depending on the context, it could mean webhooks, a WebSocket connection, server-sent events, or another way to deliver updates without the recipient requesting each one. So a webhook can be described as a kind of push, but not every push mechanism is a webhook.

The context matters because Push API can also mean the browser feature used for web push notifications. That involves a browser push service delivering messages to a user's device. A webhook usually sends an event notification from one service to an endpoint run by another service.

If someone says push API in a requirements document, ask which mechanism they mean. The name alone doesn't tell you how to configure it.

Think of an online store connected to a shipping system. When an order is completed, the store can send a webhook to the shipping system's URL. The shipping system can then start its workflow without having to keep checking the store for new orders.

A regular API call can still be useful alongside that webhook. For example, the receiving system might use an API to fetch more details about the order.

For an integration, check how delivery failures are handled. Some providers retry webhooks, so the same event may arrive more than once. The receiving system should avoid processing a duplicate as a new event, such as creating the same order twice. The provider's documentation should explain its retry behavior.