વેબહૂક શું છે? એપ્સ એકબીજાને કેવી રીતે જાણ કરે છે

વેબહૂક એ એક આપમેળે મોકલાતો સંદેશ છે, જે એક સેવા કંઈક બને તે ક્ષણે જ તમારી એપને મોકલે છે. જ્યારે ગ્રાહકનું પેમેન્ટ સફળ થાય, ત્યારે Stripe તમારી એપના એક એડ્રેસ પર વેબહૂક મોકલે છે જેમાં લખ્યું હોય "પેમેન્ટ સફળ, વિગતો અહીં છે", અને તમારી એપ પ્રતિક્રિયા આપે છે — ઓર્ડરને paid ચિહ્નિત કરે છે, રસીદ મોકલે છે, એકાઉન્ટ અનલૉક કરે છે. ટૂંકમાં: API એટલે તમારી એપ બીજી સેવાને પ્રશ્ન પૂછે છે; વેબહૂક એટલે બીજી સેવા તમારી એપને કંઈક જણાવવા કૉલ કરે છે.

AI સાથે બિલ્ડ કરતી વખતે તે શા માટે મહત્વનું છે

જેવી તમારી એપ પેમેન્ટ સ્વીકારે, બીજા tool તરફથી ફોર્મ સબમિશન મેળવે, અથવા GitHub, Shopify કે calendar જેવી સેવાઓ સાથે જોડાય, તમને વેબહૂકનો સામનો કરવો પડશે. તે સામાન્ય રીતે કંઈક બન્યું છે તે જાણવાની સાચી રીત હોય છે — પણ AI વડે બનેલી એપ્સ સૌથી વધુ સૂક્ષ્મ રીતે ખોટી હોય તે પણ ત્યાં જ હોય છે:

• એન્ડપોઇન્ટ કોઈ પણ વિનંતી સ્વીકારે છે, એટલે કોઈ પણ "પેમેન્ટ સફળ" ઘટના નકલી બનાવી શકે.
• એપ વેબહૂકને બદલે checkout redirect પેજ પર એક્સેસ આપે છે, એટલે જે લોકો ટૅબ વહેલી બંધ કરે તેમને જે ચૂકવ્યું હતું તે ક્યારેય મળતું નથી, અને જે લોકો success URL શોધે તેમને તે મફતમાં મળી જાય છે.
• એક જ ઘટના બે વાર આવે અને ગ્રાહકને બે ઓર્ડર કે બે ઈમેલ મળે.

વેબહૂક કેવી રીતે કામ કરે તે જાણવાથી તમે શરૂઆતમાં જ આ સુરક્ષા માંગી શકો છો.

રોજિંદો ઉદાહરણ: ડિલિવરીનો મેસેજ

તમારું પાર્સલ આવ્યું કે નહીં તે તમે બે રીતે જાણી શકો. તમે દર દસ મિનિટે આગળના દરવાજા સુધી ચાલીને તપાસી શકો (તે polling છે — તમારી એપ વારંવાર API ને પૂછે "કંઈ નવું?"). અથવા કુરિયર ડિલિવરી થાય ત્યારે તમને મેસેજ મોકલી શકે (તે વેબહૂક છે).

મેસેજ સ્પષ્ટપણે વધુ સારો છે — જો તમે તેના પર ભરોસો કરી શકો. જો કોઈ પણ તમને "પાર્સલ પહોંચી ગયું" મેસેજ મોકલી શકે, તો તમને ખાતરી કરવાની રીત જોઈએ કે તે ખરેખર કુરિયરે જ મોકલ્યો છે. અને જો મેસેજ આવ્યો ત્યારે તમારો ફોન બંધ હોય, તો તમે ઇચ્છો કે કુરિયર પછીથી ફરી પ્રયાસ કરે. આ બે ચિંતાઓ — ચકાસણી અને retries — વેબહૂકને અઘરા બનાવે છે.

વેબહૂક પગલા-દર-પગલા કેવી રીતે કામ કરે છે

1. તમે એન્ડપોઇન્ટ બનાવો તમારી એપના backend માં: POST વિનંતીઓ સ્વીકારતું URL, જેમ કે https://yourapp.com/webhooks/stripe.
2. તમે તે URL provider સાથે નોંધાવો અને કઈ ઘટનાઓ જોઈએ તે પસંદ કરો (દાખલા તરીકે, "checkout પૂર્ણ" અને "subscription રદ").
3. Provider તમને signing secret આપે છે. તમે તેને તમારા સર્વર પર secret તરીકે સંગ્રહો — જુઓ environment variables અને secrets.
4. ઘટના બને છે. Provider તમારા URL પર એક HTTP વિનંતી મોકલે છે, જેના JSON body માં તેનું વર્ણન હોય છે, સાથે એક signature header.
5. તમારી એપ signature ચકાસે છે, event ID નોંધે છે, ઝડપથી સફળતાનો કોડ (200) પાછો આપે છે, અને પછી કામ કરે છે.
6. જો તમારી એપ સફળતાનો જવાબ ન આપે, તો ઘણા providers પછીથી ફરી પ્રયાસ કરે છે.

Signatures

Signature સાબિત કરે છે કે વિનંતી provider તરફથી આવી છે અને તેમાં ફેરફાર થયો નથી. દાખલા તરીકે, Stripe signing secret વાપરીને request body અને timestamp પર SHA-256 સાથે HMAC (એક પ્રકારની keyed fingerprint) ગણે છે, અને તેને Stripe-Signature header માં મોકલે છે. તમારી એપ તમારી secret ની નકલ વડે એ જ ગણતરી કરે છે; જો પરિણામો મળે, તો વિનંતી સાચી છે. Timestamp પણ sign થયેલો હોવાથી, તમે જૂની વિનંતીઓ નકારી શકો છો જે કોઈએ રેકોર્ડ કરીને પછી ફરી મોકલી હોય — Stripe ની libraries ડિફૉલ્ટ રીતે પાંચ મિનિટની સહનશીલતા વાપરે છે, સપ્ટેમ્બર 2026 સુધીના તેના દસ્તાવેજ મુજબ.

એક વ્યવહારુ વિગત: signature raw request body પર ગણાય છે. જો તમારું framework ચકાસતા પહેલાં JSON parse કરીને ફરી format કરે, તો તપાસ નિષ્ફળ જાય છે. આ ખૂબ સામાન્ય bug છે.

Retries, ડુપ્લિકેટ અને ક્રમ

Providers જુદા છે, એટલે દરેકનું દસ્તાવેજ તપાસો. સપ્ટેમ્બર 2026 સુધી:

Stripe ના દસ્તાવેજ પ્રમાણે ઘટનાઓ બન્યા તે ક્રમમાં આવવાની ગેરંટી નથી, અને ક્યારેક એક જ ઘટના એક કરતાં વધુ વાર આવી શકે છે, એટલે તે event IDs ટ્રૅક કરવાની ભલામણ કરે છે.

સામાન્ય પાઠ કોઈ પણ provider માટે લાગુ પડે છે: ઘટનાઓ મોડી, એકથી વધુ વાર અને ક્રમ બહાર આવી શકે છે. તમારો handler idempotent હોવો જોઈએ — એક જ ઘટના બે વાર પ્રોસેસ કરવાની અસર એકવાર પ્રોસેસ કરવા જેટલી જ હોય.

એક ઉદાહરણ: પેઇડ કોર્સ અનલૉક કરવો

તમે ઓનલાઇન કોર્સ વેચો છો. વિદ્યાર્થી Buy પર ક્લિક કરે છે, Stripe ના hosted checkout પેજ પર પેમેન્ટ કરે છે, અને તમારી સાઇટ પર પાછો મોકલાય છે.

નાજુક રીત: "આભાર" પેજ કોર્સ અનલૉક કરે છે. જો વિદ્યાર્થી redirect દરમિયાન બ્રાઉઝર બંધ કરે, તો તેણે પૈસા ચૂકવ્યા છે પણ ઍક્સેસ નથી. જો કોઈ આભાર URL અનુમાન કરે, તો તેને ચૂકવ્યા વિના ઍક્સેસ મળી જાય.

વેબહૂક રીત:

1. Stripe પેમેન્ટની પુષ્ટિ કરે ત્યારે તે /webhooks/stripe પર checkout.session.completed ઘટના મોકલે છે.
2. તમારો backend secret વડે signature ચકાસે છે. જો નિષ્ફળ જાય, તો તે 400 આપે છે અને કંઈ કરતું નથી.
3. તે તપાસે છે કે તે event ID પહેલેથી પ્રોસેસ થયો છે કે નહીં. હા હોય, તો તે 200 આપીને અટકે છે.
4. તે event ID સાચવે છે, 200 આપે છે, અને પછી વિદ્યાર્થીને ઍક્સેસ આપે છે અને સ્વાગત ઈમેલ મોકલે છે.
5. આભાર પેજ ફક્ત કહે છે "પેમેન્ટ મળ્યું — તમારો કોર્સ થોડી જ વારમાં દેખાશે" અને વિદ્યાર્થીની ઍક્સેસ સ્થિતિ તપાસે છે.

પછીથી, જો subscription રદ થાય અથવા કાર્ડ નિષ્ફળ જાય, તો બીજી વેબહૂક ઘટનાઓ તમારી એપને ઍક્સેસ દૂર કરવા કે થોભાવવા કહે છે. આ રીતે subscription ઉત્પાદનો billing સાથે સુમેળમાં રહે છે — જુઓ SaaS શું છે અને તમારી એપમાં પેમેન્ટ કેવી રીતે ઉમેરવું.

મુખ્ય શબ્દો

• એન્ડપોઇન્ટ: તમારી એપનું URL જે વેબહૂક મેળવે છે.
• ઘટના / payload: શું બન્યું, અને તેનું વર્ણન કરતો ડેટા (સામાન્ય રીતે JSON).
• Signing secret: signatures ચકાસવા માટે વપરાતો વહેંચાયેલો secret.
• Idempotent: એ જ પરિણામ સાથે એક કરતાં વધુ વાર ચલાવવું સલામત.
• Polling: વેબહૂકની રાહ જોવાને બદલે વારંવાર API ને ફેરફારો વિશે પૂછવું.
• Tunnel: એવું સાધન જે લેપટોપને અસ્થાયી જાહેર URL આપે, જેથી વિકાસ દરમિયાન વેબહૂક તેના સુધી પહોંચી શકે.

સામાન્ય ભૂલો અને ગેરસમજો

• Signatures ન ચકાસવી. એન્ડપોઇન્ટ URL કોઈ secret નથી. ચકાસણી જ વિનંતીને વિશ્વસનીય બનાવે છે.
• જવાબ આપતા પહેલાં ધીમું કામ કરવું. જવાબ આપતા પહેલાં ઈમેલ મોકલવા કે PDF બનાવવાથી timeout થઈ શકે, જે retries ને ટ્રિગર કરે, જે ડુપ્લિકેટ બનાવે.
• ક્રમ સાથે બરાબર એકવાર માની લેવું. Event IDs નોંધો અને આગમનના ક્રમ પર આધાર ન રાખો.
• Preview URL વાપરવું. વેબહૂકને સ્થિર, જાહેર એડ્રેસ જોઈએ. ખાનગી preview અને localhost ઇન્ટરનેટ પરથી પહોંચી શકાતા નથી; તમારું publish કરેલું URL વાપરો (અથવા પરીક્ષણ વખતે tunnel).
• ટેસ્ટ અને લાઇવ secrets ભેળવવી. Providers ઘણી વાર ટેસ્ટ અને લાઇવ મોડ માટે જુદા signing secrets આપે છે. બંને સંગ્રહો અને સાચો વાપરો.
• મહત્વના નિર્ણયો માટે payload પર આંધળો ભરોસો. ઊંચા દાવવાળી ક્રિયાઓ માટે, ઘટના મળ્યા પછી provider ના API પરથી નવીનતમ સ્થિતિ મેળવવી વાજબી છે.

તમારા AI builder ને શું માંગવું

સર્વર પર POST /webhooks/stripe એન્ડપોઇન્ટ ઉમેરો. કાચા request body અને STRIPE_WEBHOOK_SECRET secret વડે Stripe signature ચકાસો. અમાન્ય signatures ને 400 થી નકારો. દરેક event ID સંગ્રહો અને પહેલેથી પ્રોસેસ થયેલી ઘટનાઓ છોડો. ઝડપથી 200 આપો, પછી checkout.session.completed સંભાળો, ઓર્ડરને paid ચિહ્નિત કરીને રસીદ મોકલો. ઘટનાનો પ્રકાર લૉગ કરો. ચેકઆઉટ સફળતા પેજ પરથી ઍક્સેસ ન આપો.

પછી તેને ટેસ્ટ કરો: provider ના dashboard માંથી ટેસ્ટ ઘટના મોકલો, એ જ ફરી મોકલો, અને ખોટી signature વાળી વિનંતી મોકલો. ફક્ત પહેલી જ કંઈક બદલવી જોઈએ.

Mythex પર વેબહૂક

Mythex અલગ webhooks સેવા ચલાવતું નથી; તમે agent ને તમારી એપના પોતાના backend માં વેબહૂક એન્ડપોઇન્ટ ઉમેરવા કહો છો, અને provider ને તમારા publish થયેલા URL તરફ નિર્દેશિત કરો, કારણ કે વેબહૂકને જાહેર એડ્રેસ જોઈએ. Signing secret તમારી project secrets માં જાય છે, અને જો તમે લાઇવ એપ પર તે બદલો, તો ફરી publish કરો. વેબહૂક હેન્ડલ કરવા પરના docs recipe માં એક starter prompt છે, અને પેમેન્ટ સ્વીકારતી એપ માટે store templates સારો પ્રારંભ બિંદુ છે.

પ્રશ્નો