# Webhook (/academy/webhook)



A normal [API](/academy/api) call is you asking. A **webhook** is them telling you, the second it matters.

You do not sit in a loop asking Stripe "did they pay yet?" You publish one public [endpoint](/academy/endpoint) — `POST /webhooks/stripe` — and you walk away. When the charge lands, Stripe knocks. The body is a receipt. You check the signature. You write a row. Then you go back to the demo.

**Asking on a timer is the long way**

That loop is polling. Fine for "refresh this list every minute." Fatal when the thing you care about lasts two seconds and your loop is asleep. A webhook flips the direction. You leave a return address. They [POST](/academy/http-methods) when the world changes.

The URL must be public. [Localhost](/academy/localhost) is invisible to Stripe. You [deploy](/academy/deploy) the route, or you tunnel it. Judges will not wait while you refresh a dashboard.

Typical knocks at a hackathon:

* Polar or Stripe: payment succeeded, or it bounced
* GitHub: a [pull request](/academy/pull-request) opened
* Your own app: a judge submitted, so Slack lights up

**Do not trust the knock**

Anyone who finds the URL can ring it. The body arriving is not proof. Verify the signature the vendor documented. Reject the rest. Update the [database](/academy/database) only after that check.

Skip the check and a stranger can fake a paid invoice. Skip deploy and the vendor cannot reach you at all. An [agent](/academy/agent) will happily scaffold the route. It will not remember the verify step unless you ask.

**What this unlocks**

You stop asking. The event comes to you.

Automation is not a person watching a screen. It is a door that only opens when something real happens.