వెబ్‌హుక్ అంటే ఏమిటి? యాప్‌లు ఒకదానికొకటి ఎలా తెలియజేస్తాయి

వెబ్‌హుక్ అనేది ఏదైనా జరిగిన క్షణంలోనే ఒక సేవ మీ యాప్‌కు పంపే ఆటోమేటిక్ సందేశం. ఒక కస్టమర్ చెల్లింపు విజయవంతమైనప్పుడు, Stripe మీ యాప్‌లోని ఒక చిరునామాకు “చెల్లింపు విజయవంతమైంది, వివరాలు ఇవిగో” అని వెబ్‌హుక్ పంపుతుంది, మరియు మీ యాప్ స్పందిస్తుంది — ఆర్డర్‌ను చెల్లించినదిగా గుర్తిస్తుంది, రసీదు పంపుతుంది, ఖాతాను అన్‌లాక్ చేస్తుంది. సంక్షిప్తంగా: API అంటే మీ యాప్ మరో సేవను ప్రశ్న అడగడం; వెబ్‌హుక్ అంటే ఆ ఇతర సేవ మీ యాప్‌కు ఏదో చెప్పడానికి కాల్ చేయడం.

AI తో నిర్మించేటప్పుడు ఇది ఎందుకు ముఖ్యం

మీ యాప్ చెల్లింపులు తీసుకున్న క్షణం, మరో టూల్ నుండి ఫారం సమర్పణలు స్వీకరించిన క్షణం, లేదా GitHub, Shopify లేదా క్యాలెండర్ వంటి సేవలకు కనెక్ట్ అయిన క్షణం, మీరు వెబ్‌హుక్‌లను ఎదుర్కొంటారు. అవి సాధారణంగా ఏదైనా జరిగిందని తెలుసుకునే సరైన మార్గం — కానీ AI తో నిర్మించిన యాప్‌లు తరచుగా సూక్ష్మంగా తప్పుగా ఉండే చోట కూడా అవే:

• ఎండ్‌పాయింట్ ఏ రిక్వెస్ట్‌నైనా అంగీకరిస్తుంది, కాబట్టి ఎవరైనా “చెల్లింపు విజయవంతమైంది” ఈవెంట్‌ను నకిలీ చేయగలరు.
• యాప్ వెబ్‌హుక్‌పై కాకుండా చెకౌట్ రీడైరెక్ట్ పేజీపై యాక్సెస్ ఇస్తుంది, కాబట్టి ట్యాబ్ త్వరగా మూసిన వ్యక్తులకు వారు చెల్లించినది రాదు, మరియు సక్సెస్ URL కనుగొన్నవారికి అది ఉచితంగా దొరుకుతుంది.
• అదే ఈవెంట్ రెండుసార్లు వస్తుంది, మరియు కస్టమర్‌కు రెండు ఆర్డర్‌లు లేదా రెండు ఇమెయిళ్లు వెళ్తాయి.

వెబ్‌హుక్‌లు ఎలా పని చేస్తాయో తెలిస్తే, ముందుగానే ఈ రక్షణలు అడగవచ్చు.

రోజువారీ ఉదాహరణ: డెలివరీ టెక్స్ట్

మీ పార్సిల్ వచ్చిందో లేదో రెండు మార్గాల్లో తెలుసుకోవచ్చు. ప్రతి పది నిమిషాలకు ముందు తలుపు దగ్గరకు వెళ్లి చూడవచ్చు (దాన్ని పోలింగ్ అంటారు — మీ యాప్ ఒక API ను పదే పదే “ఏదైనా కొత్తదా?” అని అడగడం). లేదా కొరియర్ డెలివరీ అయినప్పుడు మీకు టెక్స్ట్ పంపవచ్చు (అది వెబ్‌హుక్).

టెక్స్ట్ స్పష్టంగా మెరుగైనది — అది నిజమని మీరు నమ్మగలిగితేనే. ఎవరైనా “పార్సిల్ డెలివరీ అయింది” సందేశం పంపగలిగితే, అది నిజంగా కొరియర్ నుండే వచ్చిందని తెలుసుకునే మార్గం మీకు కావాలి. మరియు టెక్స్ట్ వచ్చినప్పుడు మీ ఫోన్ ఆఫ్‌లో ఉంటే, కొరియర్ తర్వాత మళ్లీ ప్రయత్నించాలని మీరు కోరుకుంటారు. ఆ రెండు అంశాలు — ధృవీకరణ మరియు రీట్రైలు — వెబ్‌హుక్‌లను గమ్మత్తుగా చేసేవి.

వెబ్‌హుక్ ఎలా పని చేస్తుంది, దశలవారీగా

1. మీరు ఒక ఎండ్‌పాయింట్ సృష్టిస్తారు మీ యాప్ బ్యాకెండ్‌లో: POST రిక్వెస్ట్‌లను అంగీకరించే https://yourapp.com/webhooks/stripe వంటి URL.
2. ఆ URLను ప్రొవైడర్‌తో నమోదు చేస్తారు మరియు మీకు కావలసిన ఈవెంట్‌లను ఎంచుకుంటారు (ఉదాహరణకు, “checkout completed” మరియు “subscription cancelled”).
3. ప్రొవైడర్ మీకు సైనింగ్ సీక్రెట్ ఇస్తుంది. దాన్ని ఎన్విరాన్‌మెంట్ వేరియబుల్స్ మరియు సీక్రెట్స్ ద్వారా మీ సర్వర్‌పై సీక్రెట్‌గా నిల్వ చేస్తారు.
4. ఒక ఈవెంట్ జరుగుతుంది. ప్రొవైడర్ దాన్ని వివరించే JSON బాడీ మరియు సంతకం హెడర్‌తో మీ URLకు HTTP రిక్వెస్ట్ పంపుతుంది.
5. మీ యాప్ సంతకాన్ని ధృవీకరిస్తుంది, ఈవెంట్ IDని నమోదు చేస్తుంది, త్వరగా విజయ కోడ్ (200) తో స్పందిస్తుంది, ఆపై పనిని చేస్తుంది.
6. మీ యాప్ విజయంతో స్పందించకపోతే, అనేక ప్రొవైడర్‌లు తర్వాత మళ్లీ ప్రయత్నిస్తారు.

సంతకాలు

ఒక సంతకం రిక్వెస్ట్ ప్రొవైడర్ నుండే వచ్చిందని మరియు మార్చబడలేదని రుజువు చేస్తుంది. ఉదాహరణకు Stripe, రిక్వెస్ట్ బాడీ మరియు టైమ్‌స్టాంప్‌పై, సైనింగ్ సీక్రెట్ ఉపయోగించి SHA-256 తో HMAC (కీడ్ ఫింగర్‌ప్రింట్ రకం) లెక్కిస్తుంది, మరియు దాన్ని Stripe-Signature హెడర్‌లో పంపుతుంది. మీ యాప్ తన కాపీ సీక్రెట్‌తో అదే లెక్కింపు చేస్తుంది; ఫలితాలు సరిపోతే, రిక్వెస్ట్ నిజమైనది. టైమ్‌స్టాంప్ కూడా సంతకం చేయబడినందున, ఎవరో రికార్డ్ చేసి తర్వాత మళ్లీ ప్లే చేసిన పాత రిక్వెస్ట్‌లను మీరు తిరస్కరించవచ్చు — Stripe లైబ్రరీలు, దాని డాక్యుమెంటేషన్ ప్రకారం 2026 సెప్టెంబర్ నాటికి, ఐదు నిమిషాల సహనాన్ని డిఫాల్ట్‌గా వాడతాయి.

ఒక ఆచరణాత్మక వివరాలు: సంతకం రా రిక్వెస్ట్ బాడీపై లెక్కించబడుతుంది. మీ ఫ్రేమ్‌వర్క్ ధృవీకరణకు ముందు JSONను పార్స్ చేసి మళ్లీ ఫార్మాట్ చేస్తే, తనిఖీ విఫలమవుతుంది. ఇది చాలా సాధారణ బగ్.

రీట్రైలు, నకిలీలు మరియు క్రమం

ప్రొవైడర్లు భిన్నంగా ఉంటారు, కాబట్టి ప్రతి ఒక్కరి డాక్యుమెంటేషన్ తనిఖీ చేయండి. 2026 సెప్టెంబర్ నాటికి:

ఈవెంట్‌లు జరిగిన క్రమంలోనే వస్తాయని హామీ లేదని, మరియు అదే ఈవెంట్ అప్పుడప్పుడు ఒకటి కంటే ఎక్కువసార్లు రావచ్చని Stripe డాక్యుమెంటేషన్ చెబుతుంది, కాబట్టి ఈవెంట్ IDలను ట్రాక్ చేయమని సిఫార్సు చేస్తుంది.

ఏ ప్రొవైడర్‌కైనా సాధారణ పాఠం వర్తిస్తుంది: ఈవెంట్‌లు ఆలస్యంగా, ఒకటి కంటే ఎక్కువసార్లు మరియు క్రమం తప్పి రావచ్చు. మీ హ్యాండ్లర్ ఐడెంపోటెంట్ గా ఉండాలి — అదే ఈవెంట్‌ను రెండుసార్లు ప్రాసెస్ చేయడం, ఒకసారి ప్రాసెస్ చేసినట్టే ఫలితం ఇవ్వాలి.

ఒక ఉదాహరణ: చెల్లించిన కోర్సును అన్‌లాక్ చేయడం

మీరు ఆన్‌లైన్ కోర్సు అమ్ముతున్నారు. ఒక విద్యార్థి Buy క్లిక్ చేసి, Stripe హోస్ట్ చేసిన చెకౌట్ పేజీలో చెల్లిస్తాడు, మరియు మీ సైట్‌కు తిరిగి పంపబడతాడు.

పెళుసైన మార్గం: “ధన్యవాదాలు” పేజీ కోర్సును అన్‌లాక్ చేస్తుంది. రీడైరెక్ట్ సమయంలో విద్యార్థి బ్రౌజర్ మూసివేస్తే, అతను చెల్లించాడు కానీ యాక్సెస్ లేదు. ఆ ధన్యవాదాల URL ఎవరైనా ఊహిస్తే, చెల్లించకుండానే యాక్సెస్ పొందుతారు.

వెబ్‌హుక్ మార్గం:

1. Stripe చెల్లింపును నిర్ధారించినప్పుడు, అది /webhooks/stripe కు checkout.session.completed ఈవెంట్ పంపుతుంది.
2. మీ బ్యాకెండ్ సైనింగ్ సీక్రెట్‌తో సంతకాన్ని ధృవీకరిస్తుంది. అది విఫలమైతే, 400 తో స్పందించి ఏమీ చేయదు.
3. ఆ ఈవెంట్ ID ఇప్పటికే ప్రాసెస్ అయిందా అని తనిఖీ చేస్తుంది. అవును అయితే, 200 తో స్పందించి ఆగుతుంది.
4. ఈవెంట్ IDని సేవ్ చేస్తుంది, 200 తో స్పందిస్తుంది, ఆపై విద్యార్థికి యాక్సెస్ ఇచ్చి స్వాగత ఇమెయిల్ పంపుతుంది.
5. “ధన్యవాదాలు” పేజీ కేవలం “చెల్లింపు అందింది — మీ కోర్సు కొద్ది సేపట్లో కనిపిస్తుంది” అని చెబుతుంది మరియు విద్యార్థి యాక్సెస్ స్థితిని తనిఖీ చేస్తుంది.

తర్వాత, ఒక సబ్‌స్క్రిప్షన్ రద్దు అయితే లేదా కార్డ్ విఫలమైతే, ఇతర వెబ్‌హుక్ ఈవెంట్‌లు మీ యాప్‌కు యాక్సెస్ తీసివేయమని లేదా పాజ్ చేయమని చెబుతాయి. సబ్‌స్క్రిప్షన్ ఉత్పత్తులు బిల్లింగ్‌తో ఎలా సమకాలీనంగా ఉంటాయో ఇలాగే — SaaS అంటే ఏమిటి మరియు మీ యాప్‌కు చెల్లింపులు ఎలా జోడించాలి చూడండి.

ముఖ్యమైన పదాలు

• ఎండ్‌పాయింట్: వెబ్‌హుక్‌లను స్వీకరించే మీ యాప్‌లోని URL.
• ఈవెంట్ / పేలోడ్: ఏమి జరిగింది, మరియు దాన్ని వివరించే డేటా (సాధారణంగా JSON).
• సైనింగ్ సీక్రెట్: సంతకాలను ధృవీకరించడానికి వాడే షేర్ చేసిన రహస్యం.
• ఐడెంపోటెంట్: అదే ఫలితంతో ఒకటి కంటే ఎక్కువసార్లు నడపడం సురక్షితం.
• పోలింగ్: వెబ్‌హుక్ కోసం వేచి ఉండకుండా, మార్పుల కోసం పదే పదే API ను అడగడం.
• టన్నెల్: డెవలప్‌మెంట్ సమయంలో వెబ్‌హుక్‌లు చేరేలా ల్యాప్‌టాప్‌కు తాత్కాలిక పబ్లిక్ URL ఇచ్చే టూల్.

సాధారణ తప్పులు మరియు అపోహలు

• సంతకాలను ధృవీకరించకపోవడం. ఎండ్‌పాయింట్ URL రహస్యం కాదు. ధృవీకరణే రిక్వెస్ట్‌ను విశ్వసనీయంగా చేస్తుంది.
• స్పందించే ముందు నెమ్మదైన పని చేయడం. స్పందించే ముందు ఇమెయిళ్లు పంపడం లేదా PDFలు రూపొందించడం టైమ్‌అవుట్‌లకు దారితీస్తుంది, అవి రీట్రైలకు, రీట్రైలు నకిలీలకు దారితీస్తాయి.
• సరిగ్గా ఒక్కసారి, క్రమంలో అని అనుకోవడం. ఈవెంట్ IDలను నమోదు చేయండి మరియు వచ్చిన క్రమంపై ఆధారపడకండి.
• ప్రివ్యూ URL వాడటం. వెబ్‌హుక్‌లకు స్థిరమైన, పబ్లిక్ చిరునామా కావాలి. ప్రైవేట్ ప్రివ్యూలు మరియు localhost ఇంటర్నెట్ నుండి చేరుకోలేవు; మీ ప్రచురించిన URLను వాడండి (లేదా పరీక్షించేటప్పుడు టన్నెల్).
• టెస్ట్ మరియు లైవ్ సీక్రెట్‌లను కలపడం. ప్రొవైడర్లు తరచుగా టెస్ట్ మరియు లైవ్ మోడ్‌లకు వేర్వేరు సైనింగ్ సీక్రెట్‌లు ఇస్తారు. రెండింటినీ నిల్వ చేసి సరైనది వాడండి.
• ముఖ్యమైన నిర్ణయాలకు పేలోడ్‌ను గుడ్డిగా నమ్మడం. అధిక ప్రమాదం ఉన్న చర్యలకు, ఈవెంట్ అందిన తర్వాత ప్రొవైడర్ API నుండి తాజా స్థితిని తీసుకోవడం సమంజసం.

మీ AI బిల్డర్‌ను ఏమి అడగాలి

సర్వర్‌పై POST /webhooks/stripe ఎండ్‌పాయింట్ జోడించు. రా రిక్వెస్ట్ బాడీ మరియు STRIPE_WEBHOOK_SECRET సీక్రెట్ ఉపయోగించి Stripe సంతకాన్ని ధృవీకరించు. చెల్లని సంతకాలను 400 తో తిరస్కరించు. ప్రతి ఈవెంట్ IDని నిల్వ చేసి ఇప్పటికే ప్రాసెస్ అయినవాటిని దాటవేయి. త్వరగా 200 తో స్పందించి, ఆపై checkout.session.completed ను ఆర్డర్‌ను చెల్లించినదిగా గుర్తించడం మరియు రసీదు పంపడం ద్వారా నిర్వహించు. ఈవెంట్ రకాన్ని లాగ్ చేయి. చెకౌట్ సక్సెస్ పేజీ నుండి యాక్సెస్ ఇవ్వవద్దు.

ఆ తర్వాత పరీక్షించండి: ప్రొవైడర్ డ్యాష్‌బోర్డ్ నుండి టెస్ట్ ఈవెంట్ పంపండి, అదే దాన్ని మళ్లీ పంపండి, మరియు తప్పు సంతకంతో ఒక రిక్వెస్ట్ పంపండి. మొదటిది మాత్రమే ఏదైనా మార్చాలి.

Mythex లో వెబ్‌హుక్‌లు

Mythex ప్రత్యేక వెబ్‌హుక్స్ సేవను నడపదు; మీ యాప్ యొక్క స్వంత బ్యాకెండ్‌లో వెబ్‌హుక్ ఎండ్‌పాయింట్ జోడించమని ఏజెంట్‌ను అడుగుతారు, మరియు వెబ్‌హుక్‌లకు పబ్లిక్ చిరునామా కావాలి కాబట్టి ప్రొవైడర్‌ను మీ ప్రచురించిన URL వైపు చూపిస్తారు. సైనింగ్ సీక్రెట్ మీ ప్రాజెక్ట్ సీక్రెట్స్‌లోకి వెళ్తుంది, మరియు లైవ్ యాప్‌లో దాన్ని మార్చితే మళ్లీ ప్రచురించాలి. వెబ్‌హుక్‌లను నిర్వహించడం డాక్స్ రెసిపీలో స్టార్టర్ ప్రాంప్ట్ ఉంది, మరియు చెల్లింపులు తీసుకునే యాప్‌లకు స్టోర్ టెంప్లేట్‌లు మంచి ప్రారంభ స్థానం.

ప్రశ్నలు