🔄 Sequence Diagrams: Shared WABA
In the Shared WABA model, Kloyst owns the WhatsApp API connection. Vendors prepay using a digital wallet on the platform, and deductions occur in real-time as webhooks arrive confirming delivery/conversations.
1. User Onboarding Flow​
Explanation: The user registers on the platform. A root Vendor record is immediately linked to an empty digital wallet table explicitly mapped to their vendorId.
2. Wallet Recharge Flow​
Explanation: Vendors purchase credits externally via a Payment Gateway. We do NOT credit balances purely off frontend success; we rely universally on signed Webhooks from Razorpay before locking and mutating the PostgreSQL wallet balance.
3. Template Creation & Approval​
Explanation: Since Kloyst manages the WABA, we proxy the template creation requests via our Meta developer payload to WhatsApp.
4. Shared Campaign Send Flow & Delivery Logic​
Explanation: Upon campaign launch, a rapid health check validates the Wallet balance. We offload HTTP requests to a Queue to avoid crashing our own container resources and to guarantee throttling limitations mapped against Meta's rate limits.
5. Webhook Handling & Wallet Deduction Logic (CRITICAL)​
Explanation: Meta charges for conversations, not individual messages. When the Webhook hits marking a chargeable delivery, we open a strict PostgreSQL database row-lock transaction, securely deducting the wallet balance and inserting a historical log to ensure no race-condition math errors occur during immense campaign distributions.