എന്താണ് വെബ്ഹുക്ക്? ആപ്പുകൾ പരസ്പരം അറിയിക്കുന്നത് എങ്ങനെ

വെബ്ഹുക്ക് എന്നത് എന്തെങ്കിലും സംഭവിച്ച ഉടൻ ഒരു സേവനം നിങ്ങളുടെ ആപ്പിലേക്ക് അയക്കുന്ന സ്വയമേവയുള്ള സന്ദേശമാണ്. ഒരു ഉപഭോക്താവിന്റെ പേയ്മെന്റ് വിജയിക്കുമ്പോൾ, "പേയ്മെന്റ് വിജയിച്ചു, വിവരങ്ങൾ ഇതാ" എന്ന് പറഞ്ഞ് 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-ലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു. സൈനിംഗ് സീക്രട്ട് നിങ്ങളുടെ പ്രോജക്റ്റ് സീക്രട്ടുകളിൽ ചേർക്കുന്നു, ലൈവ് ആപ്പിൽ അത് മാറ്റിയാൽ വീണ്ടും പ്രസിദ്ധീകരിക്കണം. വെബ്ഹുക്കുകൾ കൈകാര്യം ചെയ്യുന്നത് എന്ന ഡോക്സ് റെസിപ്പിയിൽ ഒരു സ്റ്റാർട്ടർ പ്രോംപ്റ്റ് ഉണ്ട്, പേയ്മെന്റുകൾ സ്വീകരിക്കുന്ന ആപ്പുകൾക്ക് സ്റ്റോർ ടെംപ്ലേറ്റുകൾ നല്ല തുടക്കമാണ്.

ചോദ്യങ്ങൾ