Webhook என்றால் என்ன? app-கள் ஒன்றுக்கொன்று தெரிவிப்பது எப்படி

Webhook என்பது ஏதாவது நடந்த அந்த நொடியில், ஒரு சேவை உங்கள் app-க்கு அனுப்பும் தானியங்கிச் செய்தி. ஒரு வாடிக்கையாளரின் பணம் வெற்றிகரமாகச் செலுத்தப்படும்போது, Stripe உங்கள் app-இல் உள்ள ஒரு முகவரிக்கு webhook அனுப்புகிறது: “பணம் வெற்றி, விவரங்கள் இதோ”, உங்கள் app அதற்கேற்ப செயல்படுகிறது — ஆர்டரை paid எனக் குறிக்கிறது, ரசீது அனுப்புகிறது, கணக்கைத் திறக்கிறது. சுருக்கமாக: API என்பது உங்கள் app மற்றொரு சேவையிடம் கேள்வி கேட்பது; webhook என்பது மற்ற சேவை உங்கள் app-ஐ அழைத்து ஏதாவது சொல்வது.

AI கொண்டு உருவாக்கும்போது இது ஏன் முக்கியம்

உங்கள் app பணம் வாங்கத் தொடங்கியதும், மற்றொரு கருவியிலிருந்து படிவச் சமர்ப்பிப்புகளைப் பெற்றதும், GitHub, Shopify அல்லது calendar போன்ற சேவைகளுடன் இணைந்ததும், webhook-களை எதிர்கொள்வீர்கள். ஏதாவது நடந்ததை அறிய அவைதான் பொதுவாக சரியான வழி — ஆனால் AI-ஆல் உருவாக்கப்பட்ட apps-இல் அவைதான் நுட்பமாகத் தவறாக அமையும் இடமும்கூட:

• எந்தக் கோரிக்கையையும் endpoint ஏற்கிறது; அதனால் யார் வேண்டுமானாலும் போலி “பணம் வெற்றி” நிகழ்வை அனுப்பலாம்.
• checkout திருப்பிவிடும் பக்கத்திலேயே app அணுகலை வழங்குகிறது, webhook-இல் அல்ல; அதனால் உலாவியை முன்கூட்டியே மூடியவர்கள் தாங்கள் செலுத்தியதைப் பெறுவதில்லை, வெற்றிப் URL-ஐக் கண்டறிந்தவர்கள் இலவசமாகப் பெறுகிறார்கள்.
• அதே நிகழ்வு இரண்டு முறை வந்து, வாடிக்கையாளருக்கு இரண்டு ஆர்டர்கள் அல்லது இரண்டு மின்னஞ்சல்கள் போகின்றன.

Webhook-கள் எப்படி வேலை செய்கின்றன என்று தெரிந்திருந்தால், முன்கூட்டியே இந்தப் பாதுகாப்புகளைக் கேட்கலாம்.

ஒரு அன்றாட உவமை: டெலிவரி குறுஞ்செய்தி

பார்சல் வந்துவிட்டதா என்று இரண்டு வழிகளில் அறியலாம். ஒவ்வொரு பத்து நிமிடமும் முன் கதவுக்குச் சென்று பார்க்கலாம் (அதுதான் polling — உங்கள் app திரும்பத் திரும்ப API-ஐ அழைத்து “ஏதாவது புதிதா?” என்று கேட்பது). அல்லது கூரியர் டெலிவரி ஆனதும் உங்களுக்கு குறுஞ்செய்தி அனுப்பலாம் (அதுதான் webhook).

நம்பகமாக இருந்தால் குறுஞ்செய்தி தெளிவாக நல்லது. “பார்சல் டெலிவரி ஆனது” என்ற செய்தியை யார் வேண்டுமானாலும் அனுப்ப முடிந்தால், அது கூரியரிடமிருந்துதான் வந்தது என்று சரிபார்க்க வழி வேண்டும். உங்கள் தொலைபேசி அணைந்திருந்தபோது செய்தி வந்திருந்தால், கூரியர் பின்னர் மீண்டும் முயற்சிக்க வேண்டும். அந்த இரண்டு அக்கறைகள் — சரிபார்ப்பும் மீண்டும் முயற்சிகளும் — webhook-களை சிக்கலாக்குபவை.

Webhook எப்படி வேலை செய்கிறது, படிப்படியாக

1. நீங்கள் ஒரு endpoint-ஐ உருவாக்குங்கள் உங்கள் app-இன் backend-இல்: POST கோரிக்கைகளை ஏற்கும் https://yourapp.com/webhooks/stripe போன்ற URL.
2. அந்த URL-ஐ வழங்குநரிடம் பதியுங்கள், எந்த நிகழ்வுகள் வேண்டும் என்று தேர்ந்தெடுங்கள் (உதாரணமாக, “checkout முடிந்தது” மற்றும் “subscription ரத்து”).
3. வழங்குநர் ஒரு signing secret-ஐத் தருவார். அதை உங்கள் சேவையகத்தில் ஒரு secret-ஆகச் சேமியுங்கள் — environment variables மற்றும் secrets-ஐப் பாருங்கள்.
4. ஒரு நிகழ்வு நடக்கிறது. வழங்குநர் நிகழ்வை விவரிக்கும் JSON உடலுடனும், ஒரு signature header-உடனும் உங்கள் URL-க்கு HTTP கோரிக்கை அனுப்புகிறார்.
5. உங்கள் app signature-ஐ சரிபார்க்கிறது, நிகழ்வின் ID-ஐப் பதிவு செய்கிறது, விரைவாக வெற்றிக் குறியீடு (200) பதில் தருகிறது, பின்னர் வேலையைச் செய்கிறது.
6. உங்கள் app வெற்றி பதிலைத் தரவில்லையென்றால், பல வழங்குநர்கள் பின்னர் மீண்டும் முயற்சிக்கின்றனர்.

Signatures

Signature என்பது கோரிக்கை வழங்குநரிடமிருந்து வந்தது என்றும், மாற்றப்படவில்லை என்றும் நிரூபிக்கிறது. உதாரணமாக Stripe, கோரிக்கையின் உடலும் நேர முத்திரையும் மீது, signing secret-ஐப் பயன்படுத்தி SHA-256 உடன் ஒரு HMAC (ஒரு வகை ரகசிய கைரேகை) கணக்கிட்டு, அதை Stripe-Signature header-இல் அனுப்புகிறது. உங்கள் app தன்னிடமுள்ள secret நகலைக் கொண்டு அதே கணக்கீட்டைச் செய்கிறது; முடிவுகள் பொருந்தினால், கோரிக்கை உண்மையானது. நேர முத்திரையும் கையொப்பமிடப்படுவதால், யாராவது பதிவு செய்து பின்னர் மீண்டும் அனுப்பும் பழைய கோரிக்கைகளை நிராகரிக்கலாம் — Stripe-இன் ஆவணப்படி, செப்டம்பர் 2026 நிலவரப்படி, அதன் நூலகங்கள் ஐந்து நிமிட சகிப்புத்தன்மையை இயல்பாக வைத்திருக்கின்றன.

ஒரு நடைமுறை விவரம்: signature கணக்கிடப்படுவது மூல (raw) கோரிக்கை உடலில். உங்கள் framework சரிபார்ப்பதற்கு முன் JSON-ஐ பகுத்து மீண்டும் வடிவமைத்தால், சரிபார்ப்பு தோல்வியடையும். இது மிகவும் பொதுவான பிழை.

மீண்டும் முயற்சிகள், நகல்கள் மற்றும் வரிசை

வழங்குநர்கள் வேறுபடுகிறார்கள்; ஒவ்வொருவரின் ஆவணத்தையும் சரிபாருங்கள். செப்டம்பர் 2026 நிலவரப்படி:

Stripe-இன் ஆவணம் மேலும் சொல்வது: நிகழ்வுகள் நடந்த வரிசையிலேயே வருவதற்கு உத்தரவாதம் இல்லை; அதே நிகழ்வு எப்போதாவது ஒன்றுக்கு மேற்பட்ட முறை வரலாம், அதனால் நிகழ்வு IDs-ஐப் பதிவு செய்யுமாறு பரிந்துரைக்கிறது.

எந்த வழங்குநருக்கும் பொருந்தும் பொதுப் பாடம் இதுதான்: நிகழ்வுகள் தாமதமாக, ஒன்றுக்கு மேற்பட்ட முறை மற்றும் தவறான வரிசையில் வரலாம். உங்கள் handler idempotent ஆக இருக்க வேண்டும் — ஒரே நிகழ்வை இரண்டு முறை செயலாக்குவது, ஒரு முறை செயலாக்குவதுபோலவே விளைவைத் தர வேண்டும்.

நடைமுறை உதாரணம்: ஒரு கட்டண பாடத்தைத் திறத்தல்

நீங்கள் ஒரு ஆன்லைன் பாடநெறியை விற்கிறீர்கள். ஒரு மாணவர் Buy பொத்தானை அழுத்தி, Stripe-இன் hosted checkout பக்கத்தில் பணம் செலுத்தி, உங்கள் தளத்துக்குத் திருப்பி அனுப்பப்படுகிறார்.

பலவீனமான வழி: “நன்றி” பக்கம் பாடநெறியைத் திறக்கிறது. திருப்பிவிடும்போது மாணவர் உலாவியை மூடினால், அவர் பணம் செலுத்தியும் அணுகல் இல்லாமல் போகிறார். நன்றிப் URL-ஐ யாராவது யூகித்தால், பணம் செலுத்தாமலேயே அணுகல் பெற்றுவிடுகிறார்.

Webhook வழி:

1. Stripe பணத்தை உறுதிசெய்ததும், /webhooks/stripe-க்கு checkout.session.completed நிகழ்வை அனுப்புகிறது.
2. உங்கள் backend signing secret-ஐக் கொண்டு signature-ஐ சரிபார்க்கிறது. அது தோல்வியடைந்தால், 400 பதில் அளித்து எதுவும் செய்யாது.
3. அந்த நிகழ்வு ID ஏற்கனவே செயலாக்கப்பட்டுள்ளதா என்று பார்க்கிறது. ஆம் எனில், 200 பதில் அளித்து நின்றுவிடுகிறது.
4. நிகழ்வு ID-ஐச் சேமித்து, 200 பதில் அளித்து, பின்னர் மாணவருக்கு அணுகல் வழங்கி வரவேற்பு மின்னஞ்சல் அனுப்புகிறது.
5. நன்றிப் பக்கம் வெறுமனே “பணம் பெறப்பட்டது — உங்கள் பாடநெறி சிறிது நேரத்தில் தோன்றும்” என்று சொல்கிறது, மேலும் மாணவரின் அணுகல் நிலையைச் சரிபார்க்கிறது.

பின்னர், ஒரு subscription ரத்து செய்யப்பட்டால் அல்லது அட்டை தோல்வியடைந்தால், வேறு webhook நிகழ்வுகள் உங்கள் app-க்கு அணுகலை நீக்கவோ இடைநிறுத்தவோ சொல்கின்றன. சந்தா தயாரிப்புகள் பில்லிங்குடன் ஒத்திசைவாக இருப்பது இப்படித்தான் — SaaS என்றால் என்ன மற்றும் உங்கள் app-க்கு பணம் செலுத்துதலைச் சேர்ப்பது எப்படி ஆகியவற்றைப் பாருங்கள்.

முக்கிய சொற்கள்

• Endpoint: webhook-களைப் பெறும், உங்கள் app-இல் உள்ள URL.
• நிகழ்வு / payload: என்ன நடந்தது, அதை விவரிக்கும் தரவு (பொதுவாக JSON).
• Signing secret: signature-களைச் சரிபார்க்கப் பயன்படும் பகிரப்பட்ட ரகசியம்.
• Idempotent: அதே முடிவுடன் ஒன்றுக்கு மேற்பட்ட முறை இயக்குவது பாதுகாப்பானது.
• Polling: webhook-க்காகக் காத்திருப்பதற்குப் பதிலாக, மாற்றங்களைக் கேட்டு API-ஐ திரும்பத் திரும்ப அழைப்பது.
• Tunnel: மேம்பாட்டின்போது webhook-கள் உங்கள் laptop-ஐ அடைய, அதற்குத் தற்காலிக பொது URL தரும் கருவி.

பொதுவான தவறுகளும் தவறான எண்ணங்களும்

• signature-ஐச் சரிபார்க்காதது. Endpoint URL ஒரு ரகசியம் அல்ல. சரிபார்ப்புதான் கோரிக்கையை நம்பகமாக்குகிறது.
• பதிலளிப்பதற்கு முன் மெதுவான வேலை செய்வது. பதிலளிக்கும் முன் மின்னஞ்சல் அனுப்புவது அல்லது PDF உருவாக்குவது timeout-ஐ ஏற்படுத்தலாம், அது மீண்டும் முயற்சிகளையும், அது நகல்களையும் உருவாக்கும்.
• சரியாக ஒரு முறை, வரிசையில் என்று கருதுவது. நிகழ்வு IDs-ஐப் பதிவு செய்யுங்கள்; வரும் வரிசையை நம்பாதீர்கள்.
• preview URL-ஐப் பயன்படுத்துவது. Webhook-களுக்கு நிலையான, பொதுவான முகவரி தேவை. தனிப்பட்ட preview-களும் localhost-உம் இணையத்திலிருந்து அடையக்கூடியவை அல்ல; வெளியிடப்பட்ட URL-ஐ பயன்படுத்துங்கள் (அல்லது சோதிக்கும்போது ஒரு tunnel).
• Test மற்றும் live secrets-ஐ கலப்பது. வழங்குநர்கள் பெரும்பாலும் test மற்றும் live முறைகளுக்கு வெவ்வேறு signing secrets தருகிறார்கள். இரண்டையும் சேமித்து சரியானதைப் பயன்படுத்துங்கள்.
• முக்கியமான முடிவுகளுக்கு payload-ஐக் குருடாக நம்புவது. உயர்-ஆபத்துள்ள செயல்களுக்கு, நிகழ்வைப் பெற்றதும் வழங்குநரின் API-இலிருந்து சமீபத்திய நிலையை எடுப்பது நியாயமானது.

உங்கள் AI builder-இடம் என்ன கேட்பது

சேவையகத்தில் POST /webhooks/stripe endpoint-ஐச் சேர். மூல கோரிக்கை உடலையும் STRIPE_WEBHOOK_SECRET secret-ஐயும் பயன்படுத்தி Stripe signature-ஐச் சரிபார். தவறான signatures-ஐ 400 உடன் நிராகரி. ஒவ்வொரு நிகழ்வு ID-ஐயும் சேமித்து, ஏற்கனவே செயலாக்கப்பட்ட நிகழ்வுகளைத் தவிர். விரைவாக 200 பதில் அளித்து, பின்னர் checkout.session.completed-ஐக் கையாண்டு ஆர்டரை paid எனக் குறித்து ரசீது அனுப்பு. நிகழ்வு வகையைப் பதிவு செய். Checkout வெற்றிப் பக்கத்திலிருந்து அணுகலை வழங்காதே.

பின்னர் அதைச் சோதியுங்கள்: வழங்குநரின் dashboard-இலிருந்து ஒரு சோதனை நிகழ்வை அனுப்புங்கள், அதே ஒன்றை மீண்டும் அனுப்புங்கள், தவறான signature உள்ள ஒரு கோரிக்கையை அனுப்புங்கள். முதலாவது மட்டுமே எதையாவது மாற்ற வேண்டும்.

Mythex-இல் Webhook-கள்

Mythex தனியான webhook சேவையை இயக்குவதில்லை; உங்கள் app-இன் சொந்த backend-இல் ஒரு webhook endpoint-ஐச் சேர்க்க agent-இடம் கேட்கிறீர்கள், வழங்குநரை உங்கள் வெளியிடப்பட்ட URL-ஐச் சுட்டிக்காட்ட வைக்கிறீர்கள். Webhook-களுக்கு பொது முகவரி தேவை. Signing secret உங்கள் project secrets-இல் செல்கிறது; நேரடி app-இல் அதை மாற்றினால், மீண்டும் வெளியிடுங்கள். webhooks-ஐக் கையாள்வது ஆவணப் recipe-இல் starter prompt உள்ளது, பணம் வாங்கும் apps-க்கு store templates ஒரு நல்ல தொடக்கப் புள்ளி.

கேள்விகள்