Webhook

How webhooks work: You give App A a URL endpoint on App B. When an event happens in App A (new payment, form submission, file upload), it sends an HTTP POST request to that URL with the event data. App B receives it instantly and can act on it. Webhooks vs. polling: Polling = App B asks App A every 5 minutes 'anything new?' (inefficient, delayed). Webhooks = App A tells App B immediately when something happens (efficient, real-time). Webhooks reduce API calls by 99%. Common webhook use cases: (1) Stripe sends payment confirmation webhook → your app activates subscription, (2) GitHub sends push webhook → CI/CD pipeline deploys code, (3) Typeform sends submission webhook → adds lead to CRM, (4) Slack receives webhook → posts message to channel. Building webhook support: If you're building a SaaS product, offer webhooks. Users want to integrate with Zapier, Make, n8n. Webhooks enable that. Provide: (1) Event types (subscription.created, payment.failed), (2) Payload structure (JSON with event data), (3) Retry logic (if endpoint is down, retry with backoff), (4) Webhook signature verification (security—prove the webhook is from you, not an attacker). Webhook security: Anyone can POST to your webhook URL. Verify authenticity: sender includes a signature (HMAC hash of payload + secret key). You recompute the hash—if it matches, the webhook is legit. Stripe, GitHub, Shopify all do this. Webhook challenges: (1) Endpoint must respond fast (200 OK) or sender retries, (2) Order not guaranteed—event 2 might arrive before event 1, (3) Duplicates possible—idempotency matters (process same webhook twice = no harm), (4) Debugging is hard—events happen async, logs are your friend.

When you buy something online and instantly get a confirmation email, that's often triggered by a payment webhook. Stripe → your backend → email service. Real-time, no polling.