Webhook vs API

A webhook is a one-way notification that fires when something happens in a system. An API is a two-way request channel that responds when you ask it a question. Both belong in every headless commerce stack. Each does a job the other does poorly. Webhooks suit events that are time-sensitive and predictable. Order created. Stock level changed. Customer support ticket opened. The producer system knows exactly when to fire the notification. The consumer does not need to poll on a schedule. APIs suit anything that requires current state or a query. Show all products in a category. Search the catalogue. Get the customer's order history. The consumer asks, the producer answers with data. ## Both patterns in a Frntkey storefront In a Frntkey storefront, both patterns run continuously. The Norce backend publishes a webhook to Junipeer when an order is placed. Junipeer routes the data to Fortnox or Business Central for accounting. No polling, no delay, no missed orders. The same storefront uses Norce's API to fetch product data when a category page loads. The API call is part of server-side rendering. The webhook is not involved in that path at all. ## How each fails The two patterns fail in different ways. A webhook fails when the consumer is offline. The producer fires, nobody is listening, the event is lost. Reliable webhook setups need retry logic on the producer side, or a queue between producer and consumer. Storyblok's content webhook to Frntkey uses both. Vercel acknowledges receipt, queues the revalidation, and tolerates short consumer outages. An API fails when the producer is overloaded. Too many concurrent requests, response times degrade, the storefront slows down. Reliable API setups need caching, rate limiting, and graceful degradation. Frntkey caches commerce API responses where the data tolerates a short delay. Product data revalidates every few minutes. Stock levels do not cache at all. ## The common mistake The common architectural mistake is using webhooks to do what an API should do. Polling a webhook receiver every minute to simulate API behaviour. Or using APIs to do what a webhook should do. Waking up a cron job every five minutes to check for new orders. Either mistake costs you real-time latency and adds operational noise. The right architecture: webhooks for events, APIs for state. Frntkey wires both by default. The Storyblok content webhook revalidates pages after a publish. The commerce API renders the storefront on every request. Each tool does what it does best.