Šta je webhook? Kako aplikacije međusobno obavještavaju

Webhook je automatska poruka koju jedan servis šalje vašoj aplikaciji čim se nešto dogodi. Kada uspješno prođe plaćanje kupca, Stripe šalje webhook na adresu u vašoj aplikaciji sa porukom „plaćanje uspješno, evo detalja”, a vaša aplikacija reaguje — označava narudžbu plaćenom, šalje račun, otključava nalog. Ukratko: API je kada vaša aplikacija postavlja pitanje drugom servisu; webhook je kada drugi servis zove vašu aplikaciju da joj nešto javi.

Zašto je važno kada pravite uz AI

Čim vaša aplikacija prima plaćanja, prima obrasce od drugog alata ili se povezuje s servisima poput GitHuba, Shopifyja ili kalendara, naići ćete na webhookove. Obično su ispravan način da saznate da se nešto dogodilo — ali upravo tu su aplikacije napravljene uz AI najčešće suptilno pogrešne:

• Krajnja tačka prihvata bilo koji zahtjev, pa svako može lažirati događaj „plaćanje uspješno”.
• Aplikacija daje pristup na stranici za preusmjeravanje nakon plaćanja umjesto na osnovu webhooka, pa ljudi koji zatvore karticu prerano ne dobiju ono što su platili, a oni koji pronađu URL uspješnog plaćanja dobiju to besplatno.
• Isti događaj stigne dvaput, pa kupac dobije dvije narudžbe ili dva mejla.

Razumijevanje kako webhookovi rade omogućava vam da zatražite zaštitu unaprijed.

Analogija iz svakodnevnog života: poruka o isporuci

Dvije su mogućnosti da saznate da je paket stigao. Možete svakih deset minuta ići do vrata da provjerite (to je polling — vaša aplikacija stalno zove API da pita „ima li šta novo?”). Ili kurir može poslati SMS kada je isporučio (to je webhook).

SMS je očigledno bolji — dok mu možete vjerovati. Ako bi bilo ko mogao slati poruku „paket isporučen”, željeli biste neki način da provjerite da je zaista stigla od kurira. A ako je telefon bio isključen kada je poruka stigla, željeli biste da kurir pokuša ponovo kasnije. Ta dva pitanja — provjera i ponovni pokušaji — čine većinu teškoća oko webhookova.

Kako webhook radi, korak po korak

1. Napravite krajnju tačku u pozadini vaše aplikacije: URL poput https://vasaaplikacija.com/webhooks/stripe koji prihvata POST zahtjeve.
2. Registrujte taj URL kod dobavljača i izaberite događaje koje želite (npr. „checkout završen” i „pretplata otkazana”).
3. Dobavljač vam daje tajnu za potpisivanje. Čuvate je kao tajnu na serveru — vidi varijable okruženja i tajne.
4. Događaj se dogodi. Dobavljač šalje HTTP zahtjev na vaš URL s JSON tijelom koje ga opisuje, plus zaglavlje s potpisom.
5. Vaša aplikacija provjerava potpis, bilježi ID događaja, brzo odgovara statusom uspjeha (200), pa tek onda obavlja posao.
6. Ako vaša aplikacija ne odgovori uspjehom, mnogi dobavljači pokušavaju ponovo kasnije.

Potpisi

Potpis dokazuje da je zahtjev stigao od dobavljača i da nije izmijenjen. Stripe, na primjer, računa HMAC (vrstu ključnog otiska) s SHA-256 nad tijelom zahtjeva i vremenskom oznakom, koristeći tajnu za potpisivanje, i šalje ga u zaglavlju Stripe-Signature. Vaša aplikacija radi isti proračun sa svojom kopijom tajne; ako se rezultati poklope, zahtjev je autentičan. Pošto je i vremenska oznaka potpisana, možete odbaciti stare zahtjeve koje je neko snimio i kasnije ponovio — Stripeove biblioteke po defaultu imaju toleranciju od pet minuta, prema njegovoj dokumentaciji iz septembra 2026.

Jedan praktičan detalj: potpis se računa nad sirovim tijelom zahtjeva. Ako vaš framework parsira i ponovo oblikuje JSON prije provjere, provjera ne prolazi. Ovo je vrlo česta greška.

Ponovni pokušaji, duplikati i redoslijed

Dobavljači se razlikuju, pa provjerite dokumentaciju svakog. Od septembra 2026:

Stripeova dokumentacija takođe kaže da događaji nisu garantovano stigli onim redom kojim su se dogodili, te da isti događaj povremeno može stići više puta, pa preporučuje praćenje ID-jeva događaja.

Opšta pouka važi za svakog dobavljača: događaji mogu stići kasno, više puta i nepravilnim redoslijedom. Obrada treba biti idempotentna — obrada istog događaja dvaput ima isti efekat kao jednom.

Radni primjer: otključavanje plaćenog kursa

Prodajete online kurs. Student klikne Kupi, plati na Stripeovoj hostovanoj stranici za plaćanje i vrati se na vaš sajt.

Krhak način: stranica „hvala” otključa kurs. Ako student zatvori pretraživač tokom preusmjeravanja, platio je ali nema pristup. Ako neko pogodi URL stranice „hvala”, dobija pristup bez plaćanja.

Način s webhookom:

1. Kada Stripe potvrdi plaćanje, šalje događaj checkout.session.completed na /webhooks/stripe.
2. Vaša pozadina provjerava potpis tajnom za potpisivanje. Ako ne prođe, odgovara 400 i ne radi ništa.
3. Provjerava da li je taj ID događaja već obrađen. Ako jeste, odgovara 200 i staje.
4. Bilježi ID događaja, odgovara 200, pa dodjeljuje studentu pristup i šalje dobrodošlu e-poštu.
5. Stranica „hvala” samo kaže „Plaćanje primljeno — vaš kurs će se uskoro pojaviti” i provjerava status pristupa studenta.

Kasnije, ako se pretplata otkaže ili kartica ne prođe, drugi webhook događaji govore vašoj aplikaciji da ukloni ili pauzira pristup. Tako se proizvodi na pretplatu drže usklađenima s naplatom — vidi šta je SaaS i kako dodati plaćanja u aplikaciju.

Ključni pojmovi

• Krajnja tačka (endpoint): URL u vašoj aplikaciji koji prima webhookove.
• Događaj / payload: šta se dogodilo i podaci koji to opisuju (obično JSON).
• Tajna za potpisivanje: zajednička tajna koja se koristi za provjeru potpisa.
• Idempotentno: sigurno za pokretanje više puta s istim rezultatom.
• Polling: ponovljeno pitanje API-ja za promjene umjesto čekanja webhooka.
• Tunel: alat koji laptopu daje privremeni javni URL da webhookovi mogu doći do njega tokom razvoja.

Česte greške i zablude

• Neprovjeravanje potpisa. URL krajnje tačke nije tajna. Provjera je ono što zahtjev čini pouzdanim.
• Sporo rade prije odgovora. Slanje e-pošte ili generisanje PDF-a prije odgovora može izazvati timeout, što pokreće ponovne pokušaje, a oni duplikate.
• Pretpostavka „tačno jednom, po redu”. Bilježite ID-jeve događaja i ne oslanjajte se na redoslijed dolaska.
• Korištenje URL-a pregleda. Webhookovima treba stabilna, javna adresa. Privatni pregledi i localhost nisu dostupni s interneta; koristite objavljeni URL (ili tunel tokom testiranja).
• Mješanje testnih i živih tajni. Dobavljači često izdaju različite tajne za potpisivanje za testni i živi režim. Čuvajte obje i koristite pravu.
• Slijepo vjerovanje sadržaju za važne odluke. Za radnje velikog rizika razumno je nakon primanja događaja dohvatiti najnovije stanje preko API-ja dobavljača.

Šta tražiti od vašeg AI alata

Dodaj POST /webhooks/stripe krajnju tačku na serveru. Provjeri Stripe potpis koristeći sirovo tijelo zahtjeva i tajnu STRIPE_WEBHOOK_SECRET. Odbij neispravne potpise sa 400. Čuvaj ID svakog događaja i preskoči događaje koji su već obrađeni. Odgovori brzo sa 200, pa obradi checkout.session.completed tako što ćeš označiti narudžbu plaćenom i poslati račun. Zapisuj tip događaja. Ne dodjeljuj pristup sa stranice uspješnog plaćanja.

Zatim ga testirajte: pošaljite testni događaj iz kontrolne table dobavljača, pošaljite isti ponovo i pošaljite zahtjev s pogrešnim potpisom. Samo prvi bi trebalo nešto da promijeni.

Webhookovi u Mythexu

Mythex ne pokreće zasebni servis za webhookove; od agenta tražite da doda krajnju tačku za webhook u pozadini vaše aplikacije, a dobavljaču dajete vaš objavljeni URL, jer webhookovi trebaju javnu adresu. Tajna za potpisivanje ide u tajne vašeg projekta, a ako je promijenite na živoj aplikaciji, ponovo objavite. Recept u dokumentaciji o obradi webhookova ima početni prompt, a šabloni prodavnica su dobar početak za aplikacije koje primaju plaćanja.

Pitanja