Šta je webhook? Kako aplikacije obaveštavaju jedna drugu

Webhook je automatska poruka koju jedan servis šalje vašoj aplikaciji čim se nešto desi. Kada plaćanje kupca uspe, Stripe šalje webhook na adresu u vašoj aplikaciji sa porukom „plaćanje uspelo, evo detalja”, a aplikacija reaguje — označi porudžbinu kao plaćenu, pošalje račun, otključa nalog. Ukratko: API je kada vaša aplikacija postavi pitanje drugom servisu; webhook je kada drugi servis zove vašu aplikaciju da joj nešto saopšti.

Zašto je važan kad pravite sa AI

Čim vaša aplikacija prima plaćanja, prima podneske formulara iz drugog alata ili se povezuje sa servisima poput GitHub-a, Shopify-a ili kalendara, naići ćete na webhook-ove. Obično su to ispravan način da saznate da se nešto dogodilo, ali su i mesto gde su aplikacije pravljene uz AI najčešće suptilno pogrešne:

• Krajnja tačka prihvata svaki zahtev, pa svako može da napravi lažni događaj „plaćanje uspelo”.
• Aplikacija daje pristup na stranici za preusmeravanje nakon plaćanja umesto na webhook-u, pa kupci koji zatvore karticu rano nikada ne dobiju ono što su platili, a ljudi koji pronađu adresu uspeha dobijaju pristup besplatno.
• Isti događaj stigne dva puta, pa kupac dobije dve porudžbine ili dva email-a.

Kada znate kako webhook-ovi rade, možete unapred da zatražite te zaštite.

Svakodnevna analogija: SMS o isporuci

Možete saznati da li je paket stigao na dva načina. Možete svakih deset minuta da idete do ulaznih vrata da proverite (to je polling — vaša aplikacija stalno zove API da pita „ima li nešto novo?”). Ili vam kurir pošalje SMS kada je isporučeno (to je webhook).

SMS je očigledno bolji — dok mu možete verovati. Ako bi bilo ko mogao da vam pošalje poruku „paket isporučen”, želeli biste način da znate da je stvarno stigla od kurira. A ako vam je telefon bio isključen kada je poruka stigla, želeli biste da kurir pokuša ponovo kasnije. Ta dva pitanja — provera i ponovni pokušaji — čine najveći deo onoga što webhook-ove čini zahtevnim.

Kako webhook radi, korak po korak

1. Napravite krajnju tačku u pozadini vaše aplikacije: adresu poput https://yourapp.com/webhooks/stripe koja prihvata POST zahteve.
2. Registrujte tu adresu kod provajdera i izaberite koje događaje želite (na primer, „checkout završen” i „pretplata otkazana”).
3. Provajder vam daje tajnu za potpisivanje. Čuvate je kao tajnu na serveru — pogledajte promenljive okruženja i tajne.
4. Desi se događaj. Provajder šalje HTTP zahtev na vašu adresu sa JSON telom koje ga opisuje, plus zaglavlje sa potpisom.
5. Vaša aplikacija proverava potpis, beleži ID događaja, brzo odgovara statusom uspeha (200), a zatim obavlja posao.
6. Ako vaša aplikacija ne odgovori uspehom, mnogi provajderi pokušavaju ponovo kasnije.

Potpisi

Potpis dokazuje da zahtev dolazi od provajdera i da nije menjan. Stripe, na primer, računa HMAC (vrstu ključnog otiska) sa SHA-256 nad telom zahteva 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 poklapaju, zahtev je pravi. Pošto je i vremenska oznaka potpisana, možete odbiti stare zahteve koje je neko snimio i kasnije ponovo pustio — Stripe-ove biblioteke po podrazumevanoj vrednosti dozvoljavaju pet minuta odstupanja, prema njegovoj dokumentaciji iz septembra 2026.

Jedan praktičan detalj: potpis se računa nad sirovim telom zahteva. Ako vaš framework parsira i ponovo formatira JSON pre nego što proverite, provera pada. Ovo je vrlo česta greška.

Ponovni pokušaji, duplikati i redosled

Provajderi se razlikuju, zato proverite dokumentaciju svakog. Od septembra 2026:

Stripe-ova dokumentacija takođe kaže da događaji nisu zagarantovano stigli redom kojim su se desili i da isti događaj ponekad može da stigne više puta, pa preporučuje praćenje ID-jeva događaja.

Opšta pouka važi za svakog provajdera: događaji mogu da stignu kasno, više puta i van redosleda. Vaš handler treba da bude idempotentan — obrada istog događaja dvaput ima isti efekat kao obrada jednom.

Radni primer: otključavanje plaćenog kursa

Prodajete onlajn kurs. Student klikne Kupi, plati na Stripe-ovoj hostovanoj stranici za plaćanje i vrati se na vaš sajt.

Krhak način: stranica „hvala” otključava kurs. Ako student zatvori pregledač tokom preusmeravanja, platio je ali nema pristup. Ako neko pogodi adresu stranice „hvala”, dobija pristup bez plaćanja.

Način sa webhook-om:

1. Kada Stripe potvrdi plaćanje, šalje događaj checkout.session.completed na /webhooks/stripe.
2. Vaša pozadina proverava potpis tajnom za potpisivanje. Ako ne prođe, odgovara 400 i ne radi ništa.
3. Proverava da li je taj ID događaja već obrađen. Ako jeste, odgovara 200 i staje.
4. Čuva ID događaja, odgovara 200, a zatim studentu daje pristup i šalje dobrodošlu poruku.
5. Stranica „hvala” samo kaže „Plaćanje primljeno — vaš kurs će se pojaviti za trenutak” i proverava 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 proizvodi na pretplatu ostaju usklađeni sa naplatom — pogledajte šta je SaaS i kako dodati plaćanja u aplikaciju.

Ključni pojmovi

• Krajnja tačka (endpoint): adresa u vašoj aplikaciji koja prima webhook-ove.
• Događaj / payload: šta se dogodilo i podaci koji to opisuju (obično JSON).
• Tajna za potpisivanje: zajednička tajna koja se koristi za proveru potpisa.
• Idempotentan: bezbedan za pokretanje više puta sa istim rezultatom.
• Polling: ponavljano pitanje API-ja za izmene umesto čekanja webhook-a.
• Tunel: alat koji laptopu daje privremenu javnu adresu da webhook-ovi stignu tokom razvoja.

Česte greške i zablude

• Neprovjeravanje potpisa. URL krajnje tačke nije tajna. Provera je ono što čini zahtev pouzdanim.
• Sporo rad pre odgovora. Slanje email-ova ili generisanje PDF-ova pre odgovora može dovesti do isteka vremena, što pokreće ponovne pokušaje, što stvara duplikate.
• Pretpostavka da se događaj dešava tačno jednom, redom. Beležite ID-jeve događaja i ne oslanjajte se na redosled dolaska.
• Korišćenje adrese za pregled. Webhook-ovima treba stabilna javna adresa. Privatni pregledi i localhost nisu dostupni sa interneta; koristite objavljenu adresu (ili tunel dok testirate).
• Mešanje test i live tajni. Provajderi često izdaju različite tajne za potpisivanje u test i live režimu. Čuvajte obe i koristite ispravnu.
• Slepo verovanje podacima iz payload-a za važne odluke. Za radnje sa visokim rizikom razumno je da posle primanja događaja preuzmete najnovije stanje iz API-ja provajdera.

Šta tražiti od AI alata

Dodaj POST /webhooks/stripe krajnju tačku na serveru. Proveri Stripe potpis koristeći sirovo telo zahteva i tajnu STRIPE_WEBHOOK_SECRET. Odbij neispravne potpise sa 400. Sačuvaj svaki ID događaja i preskoči događaje koji su već obrađeni. Brzo odgovori sa 200, zatim obradi checkout.session.completed tako što ćeš označiti porudžbinu kao plaćenu i poslati račun. Zabeleži tip događaja. Ne daji pristup sa stranice za uspešno plaćanje.

Zatim ga testirajte: pošaljite test događaj sa kontrolne table provajdera, pošaljite isti ponovo i pošaljite zahtev sa pogrešnim potpisom. Samo prvi treba da promeni nešto.

Webhook-ovi u Mythex-u

Mythex nema poseban servis za webhook-ove; zamolite agenta da doda krajnju tačku za webhook u pozadinu vaše aplikacije, a provajdera usmerite na vašu objavljenu adresu, jer webhook-ovima treba javna adresa. Tajna za potpisivanje ide u tajne vašeg projekta, a ako je promenite na živoj aplikaciji, ponovo objavite. Recept u dokumentaciji za obradu webhook-ova ima početni prompt, a šabloni prodavnica su dobro polazište za aplikacije koje primaju plaćanja.

Pitanja