Webhook alternative
A Webhook Alternative for Applications Without Public Endpoints
Polling is useful when a receiving application cannot reliably expose a public inbound HTTP endpoint.
Webhooks and polling solve different network problems
A webhook lets a sender call the receiver when an event occurs. It is a strong choice when the receiver has a stable inbound endpoint, can authenticate incoming requests and can operate a reliable retry path.
Polling reverses the connection direction. The receiver makes outbound requests on its own schedule and retrieves work that is waiting in its mailbox.
| Capability | Webhook | Polling |
|---|---|---|
| Public inbound endpoint | Usually required | Not required |
| Receiver controls connection | No | Yes |
| Typical latency | Lower | Depends on polling interval |
| Firewall or NAT friendliness | More configuration | Often simpler |
| Intermittent receiver | Needs retry handling | Natural fit |
When polling is a practical choice
Polling can fit private networks, NAT, firewalls, shared hosting, local gateways, legacy applications and intermittently connected customer-installed software. It trades immediate delivery for receiver control and a simpler inbound security boundary.
How HeartbeatHook uses polling
The sender creates a signed signal. The target application later calls GET /heartbeat/signals, processes the returned pending records and calls the ACK route. This is a relay pattern, not a webhook endpoint and not a generic queue.
Choose the approach based on topology, latency, retry ownership and operational constraints. No one transport is universally better.