Webhook
A webhook is a mechanism for automatically sending data from one system to another the moment an event occurs. Instead of constantly checking whether something has changed (polling), a webhook pushes the information immediately — in real time.
A webhook is an "HTTP callback" mechanism for automatically sending data from one system to another the instant a specific event occurs — for example, a new order, a shipping status change, or an inventory update. The traditional alternative is polling: repeatedly asking the other system 'has anything changed?' — a process that wastes resources and always introduces a delay between the actual change and when it's noticed. A webhook flips the direction: the system where the event happened sends an HTTP request to a pre-configured URL the moment it occurs, so the data arrives almost instantly with no unnecessary server load. StoreChart uses webhooks in both directions: receiving events from connected stores (a new order on WooCommerce or Shopify) and sending events to external systems (such as an automatic WhatsApp alert or an accounting system update) — the foundation behind most of the platform's automations.
Reliability is the practical challenge with webhooks: unlike polling, where a missed check simply gets caught on the next cycle, a webhook delivery that fails (the receiving server was briefly down, or timed out) needs its own retry mechanism, or the event is lost entirely. This is why production webhook systems pair delivery with automatic retries (attempting delivery again with increasing delay) and a signed payload (so the receiving side can verify the request genuinely came from the sending system and wasn't forged by a third party who discovered the endpoint URL).
Webhooks are what let StoreChart stay in sync with WooCommerce, payment processors, and other connected systems without constantly asking 'anything new?' — the moment an order is placed or a payment settles on the other end, that system pushes the event immediately instead of the platform having to poll every few minutes and miss anything that happened in between. The trade-off is that a webhook delivery can occasionally fail or arrive out of order, which is why reliable integrations pair webhooks with a fallback reconciliation pass rather than trusting delivery blindly.
When debugging a sync issue between two connected systems, checking whether the expected webhook actually fired (and what payload it carried) is almost always the first diagnostic step, since a missing or malformed webhook delivery is the single most common root cause of two systems silently drifting out of sync.
Related StoreChart features
Frequently asked questions
The receiving side must be always available to accept the incoming request, and building a correct implementation (signature verification, idempotent handling of retries) takes more upfront engineering than a simple scheduled polling script.
A well-built system automatically retries the delivery a limited number of times with increasing delay between attempts, and logs the failure for review if every retry fails, rather than silently dropping the event.
Not directly — a webhook is a one-way push from the sending system to the receiving URL. Two-way communication typically pairs a webhook (for real-time push) with a regular API call (for the receiving system to request additional data back).