WhatsApp + SMS OTP & Transactional Notifications

الميزات الرئيسية

OTP generation with hashed, time-boxed codes stored via a dedicated otp.request model — plain codes are never persisted

One-time-password verification endpoint with attempt counting, lockout, and a computed state field (pending/verified/expired/locked) using @api.depends

Dual-channel delivery: WhatsApp Business Cloud API as primary with automatic SMS fallback when WhatsApp is undeliverable or the number is not WhatsApp-enabled

Event-driven transactional alerts triggered off native Odoo models — sale.order confirmation, stock.picking delivery, account.payment received

Per-event QWeb message templates with dynamic placeholders (order number, tracking link, amount, customer name) editable by admins without code

Configurable rate limiting per phone number, per event, and per time window to prevent abuse and control provider spend

Automatic retry with backoff on transient failures via ir.cron scheduled actions, with a dead-letter state for permanent failures

Provider abstraction layer supporting Meta WhatsApp Cloud API, Twilio, Vonage, MessageBird or a regional SMS gateway, selectable in Settings

Full message log model recording channel used, provider message id, delivery/read receipt, cost reference and error detail for audit and reconciliation

Delivery-status webhook receiver that updates each message's state from provider callbacks (sent → delivered → read / failed)

Settings panel (res.config.settings) for credentials, sender IDs, default channel, OTP length, expiry window and per-event enable/disable toggles

Multi-company and multi-language aware: templates resolve to the partner's language and messages respect company boundaries via record rules

Security hardening with ir.model.access.csv plus record rules so only authorized users read message logs and OTP records

XML-RPC / JSON-RPC methods to generate, send and verify OTPs from external apps, storefronts or middleware

Opt-out and consent tracking fields on partners to respect messaging preferences and regional compliance

مبني حسب الطلب، ننجزه بالكامل لك

لا إعداد يدوي — تطبيق جاهز يبنيه ويثبّته ويدعمه ECOSIRE.

تطلب

ابدأ بسعر بناء لمرة واحدة. نحدّد النطاق معك عند الانطلاق.

نبني ونثبّت

يقوم ECOSIRE ببنائه وتهيئته وتثبيته على Odoo الخاص بك.

الإطلاق + الدعم

تنطلق خلال 2–4 أسابيع تقريبًا، مع فترة دعم بعد الإطلاق.

عن هذا المنتج

Verify users and keep them informed the way they actually read messages — on WhatsApp and SMS. This is a build-to-order Odoo module that ECOSIRE designs, develops, installs and supports for your specific stack; it is not an instant apps.odoo.com download. After purchase our engineers scope your triggers, provider and templates, then deliver a production-ready module for Odoo 17, 18 or 19 (Community or Enterprise) within a typical 2–4 week lead time.

At its core the module adds a dual-channel messaging service layer to Odoo. A dedicated otp.request model generates time-boxed, hashed one-time passwords, tracks attempt counts and expiry via a computed state field with @api.depends, and verifies codes without ever storing them in plain text. Transactional notifications are driven by Odoo's own business events: a confirmed sale order (sale.order), a validated delivery (stock.picking), a registered payment (account.payment), or a portal/backend login all fire a message through your chosen provider using per-event QWeb-rendered templates.

Delivery is resilient by design. Every send attempts your primary channel (typically WhatsApp Business Cloud API) and automatically falls back to SMS when WhatsApp is undeliverable, the number is not WhatsApp-enabled, or the provider returns a failure. Odoo ir.cron scheduled actions handle retries with backoff, and a configurable rate limiter protects you from abuse and runaway spend. Provider credentials, sender IDs and per-event toggles live in a proper Settings panel, and every message is logged with its status, channel, cost reference and delivery receipt for audit.

Because we build it against your database, the module fits your data model rather than forcing you into a generic one: your partner phone fields, your multi-company boundaries, your record rules. We wire the provider you prefer (Meta WhatsApp Cloud API, Twilio, Vonage, MessageBird, or a regional SMS gateway), secure everything with ir.model.access.csv and record rules, expose XML-RPC/JSON-RPC endpoints if you need to trigger sends from external systems, and hand over clean, documented, upgrade-friendly code you fully own.

ما تحصل عليه

Complete, documented Odoo module (models, views, security, data, QWeb templates) with a valid __manifest__.py targeting your Odoo 17, 18 or 19 (Community or Enterprise) version

Installation and deployment on your server or Odoo.sh, including provider credential setup and go-live verification against a real test number

Provider integration configured end-to-end for your chosen gateway (WhatsApp Cloud API plus at least one SMS fallback provider) with webhook endpoints wired

Event mapping worksheet and configured triggers for your specific flows — which order/delivery/payment/login events fire which message

Admin and end-user documentation: how to edit templates, read the message log, manage rate limits, and rotate provider keys

A live training/handover session (recorded) for your team plus the source code and repository access — you own the module

Post-delivery support window (30 days by default) covering bug fixes and configuration adjustments, with optional extended support/SLA

Test evidence: OTP send/verify, WhatsApp-to-SMS fallback, retry behavior and rate-limit enforcement demonstrated in your environment

لمن هذا

eCommerce / Odoo Website store owner

Runs Odoo eCommerce or the website portal and needs verified checkouts plus order, shipping and payment updates delivered where customers actually read them — WhatsApp first, SMS as a guaranteed fallback.

Operations / fulfillment manager

Owns delivery and warehouse flows in Inventory. Wants stock.picking validations to automatically notify customers with tracking links, and payment confirmations to go out without staff copy-pasting messages.

IT / Odoo administrator

Responsible for security and access. Needs login OTP challenges, clean ir.model.access.csv and record rules, an auditable message log, and provider keys managed safely — all upgrade-friendly across Odoo versions.

Customer support lead

Fields 'where is my order?' and 'I can't log in' tickets. Wants proactive transactional alerts and reliable OTP delivery to cut inbound volume and reduce failed-login frustration.

كيف يقارن WhatsApp + SMS OTP & Transactional Notifications.

المعيار	ECOSIRE	بناء مخصص	منافس	Odoo الأصلي
Odoo-native OTP over WhatsApp + SMS with automatic fallback	متضمنة	Possible but you build the whole fallback engine yourself	Rarely both channels; fallback often absent	غير متضمنة
Transactional alerts triggered off sale.order / stock.picking / account.payment events	متضمنة	Yes, if you wire every model event correctly	Partial — usually one or two events, fixed	دعم جزئي
Login / portal OTP challenge for res.users	متضمنة	Yes, but security-sensitive to get right	غير متضمنة	غير متضمنة
Fit to your exact data model, phone fields and multi-company rules	متضمنة	متضمنة	no — generic, take-it-or-leave-it	دعم جزئي
Rate limiting, retry with backoff and dead-letter handling	متضمنة	You design and test it all	دعم جزئي	غير متضمنة
Auditable per-message log with delivery/read receipts and cost reference	متضمنة	Build the log model and webhook receiver yourself	دعم جزئي	غير متضمنة
Editable per-event QWeb templates, multi-language, no code needed	متضمنة	متضمنة	partial — limited placeholders	دعم جزئي
Installation, go-live verification, training and a support window	متضمنة	Your team's time and risk	no — download and self-integrate	غير متضمنة
You own documented, upgrade-friendly source across Odoo 17/18/19	متضمنة	متضمنة	partial — vendor-locked, per-seat or annual	متضمنة

الأسئلة المتداولة حول WhatsApp + SMS OTP & Transactional Notifications

How long until the module is delivered, and what happens after I purchase?

This is a build-to-order module, not an instant download. Typical lead time is 2–4 weeks depending on how many events and which provider you need. After purchase we scope your triggers, provider and templates in a short kickoff, build against your Odoo 17/18/19 (Community or Enterprise) database, test in a staging copy, then install and verify go-live with a real test number. You receive the source code, documentation and a training session at handover.

What support and updates are included after delivery?

A 30-day post-delivery support window is included by default, covering bug fixes and configuration adjustments (new templates, tweaked rate limits, event changes). Because you receive the full source, you own the module. We offer optional extended support and SLA plans, and paid version-migration when you upgrade your Odoo major version — the code is written to be upgrade-friendly, but provider APIs and Odoo internals do change over time.

Which messaging providers do you integrate, and do I need a WhatsApp Business account?

We build against a provider abstraction layer and wire the gateway you prefer: Meta WhatsApp Business Cloud API for WhatsApp, and Twilio, Vonage, MessageBird or a regional SMS gateway for the SMS fallback. You do need your own WhatsApp Business / provider accounts and approved message templates (we guide you through template approval). Provider messaging fees are billed by them directly, not by ECOSIRE.

How does the WhatsApp-to-SMS fallback actually work?

Every notification attempts your primary channel first (usually WhatsApp). If WhatsApp returns an error, the destination number isn't WhatsApp-enabled, or no delivery confirmation arrives within a configurable window, the module automatically re-sends the same templated message over SMS. An ir.cron scheduled action also handles retries with backoff, and each attempt is recorded in the message log with its channel and status.

Is it secure, and are OTP codes stored in the database?

OTP codes are never stored in plain text — the otp.request model keeps a salted hash, an expiry timestamp and an attempt counter, and verification compares against the hash. Access is locked down with ir.model.access.csv and record rules so only authorized users can view OTP records and message logs. Rate limiting per number and per event prevents brute-force and abuse, and provider credentials live in configuration rather than in code.

Can external systems trigger OTPs and alerts, and does it work with multi-company setups?

Yes. The module exposes XML-RPC/JSON-RPC methods to generate, send and verify OTPs from an external storefront, mobile app or middleware. It is multi-company and multi-language aware: messages respect company boundaries through record rules, and QWeb templates render in the recipient partner's language automatically.