Skip to main content
Asynchronous changes पर प्रतिक्रिया करने के लिए webhooks का उपयोग करें। Delivery कम से कम एक बार है, इसलिए duplicate, delayed, और out of order events सामान्य हैं।

केवल आवश्यक events register करें

एक endpoint को POST /v3/webhooks के साथ बनाएँ। केवल दस्तावेज़ीकृत events की सदस्यता लें जो आपके integration को drive करते हैं। यह उदाहरण transfer.state_changed का उपयोग करता है।
Response data.id को WEBHOOK_ID के रूप में संग्रहीत करें। GET /v3/webhooks/portal द्वारा लौटाए गए portal को खोलें, इस endpoint की signing secret प्राप्त करें, और इसे अपनी API key से अलग एक secret manager में संग्रहीत करें।

Parsing से पहले verify करें

Swipelux नए webhook integrations को Svix के माध्यम से deliver करता है। अपनी endpoint signing secret और इन headers के साथ raw request body को verify करें:
  • svix-id
  • svix-timestamp
  • svix-signature
Verification सफल होने से पहले JSON parse न करें या side effects का कारण न बनें।
अनुपस्थित या अमान्य signatures वाले requests को अस्वीकार करें। Verification पूरा होने तक raw body उपलब्ध रखें।

Persist, acknowledge, फिर process

Envelope id पर एक uniqueness constraint लगाएँ। Verified envelope को persist करें, तुरंत 2xx लौटाएँ, फिर इसे asynchronously process करें। यदि event ID पहले से मौजूद है, तो पूर्ण किए गए side effects को दोहराए बिना delivery को acknowledge करें। अपनी retry queue के माध्यम से pending या failed local work को फिर से शुरू करें। Envelope attempt field को deduplication key या transport retry counter के रूप में उपयोग न करें।

वर्तमान state पुन: प्राप्त करें

Webhook order एक authoritative resource history नहीं है। Object का पता लगाने के लिए resource.type और resource.id का उपयोग करें, फिर अपने system को update करने से पहले इसकी वर्तमान state प्राप्त करें। एक transfer event के लिए, GET /v3/transfers/{transferId} को call करें:
वर्तमान API response से customer-visible status और downstream actions को drive करें। Side effects को इस तरह design करें कि यदि दो workers संबंधित events को अलग order में process करें तो सुरक्षित रहें।

Deliveries recover करें

Delivery logs खोलने, failed deliveries retry करने, या manual replay शुरू करने के लिए GET /v3/webhooks/portal का उपयोग करें। प्रत्येक replay को उसी signature verification और durable inbox से गुजरना होगा। Downtime के बाद recover करने के लिए, प्रभावित window को replay करें और प्रत्येक संदर्भित resource को पुन: प्राप्त करें। पूर्ण किए गए event IDs no-ops रहते हैं; अपूर्ण records asynchronously फिर से शुरू होते हैं। आगे, sandbox में duplicate और out-of-order deliveries को verify करें, फिर Go live checklist पूरी करें।