Aperçu illustratifOne Odoo SMS framework routing through Twilio, Vonage,
Plivo, MessageBird, Telnyx, TeleSign & D7 with failover and least-cost routing.
Qu'est-ce que Multi-Provider SMS Gateway Hub ?
One Odoo SMS framework routing through Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign & D7 with failover and least-cost routing. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Fonctionnalités clés
Fait sur commande, clé en main
Aucune configuration à faire vous-même — une app fonctionnelle conçue, installée et prise en charge par ECOSIRE.
- 1
Vous commandez
Commencez par un prix de développement unique. Nous cadrons le projet avec vous au lancement.
- 2
Nous développons et installons
ECOSIRE la développe, la configure et l'installe sur votre Odoo.
- 3
Mise en ligne + assistance
Vous êtes en ligne en une semaine ouvrée environ, avec deux semaines d’assistance après la mise en production. Les défauts du code que nous livrons sont corrigés gratuitement.
Spécifications techniques
- Compatibilité Odoo
- Odoo 17, Odoo 18, Odoo 19
- Éditions
- Enterprise et Community
- Licence
- Licence à confirmer
- Version Python requise
- Python 3.10+
- Base de données
- PostgreSQL 12+
À propos de ce produit
Odoo's native SMS gateway is single-provider by design: one IAP account, one route, one point of failure. If your primary provider throttles you, blocks a destination country, or has an outage, your OTPs, order alerts, and marketing blasts simply stop — and there is no built-in way to fall back or shop for a cheaper route per destination.
Multi-Provider SMS Gateway Hub replaces that single lane with a pluggable routing framework. ECOSIRE builds a custom Odoo module (sms_gateway_hub) that introduces a provider-abstraction layer on top of Odoo's sms.sms / sms.api stack, so every outbound message — transactional or bulk — is dispatched through a routing engine that evaluates health, cost, and per-country rules before it picks a gateway. Seven providers ship connected out of the box: Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign, and D7, each implemented as a discrete sms.gateway.provider record with its own credentials, sender IDs, and REST adapter.
This is not an off-the-shelf apps.odoo.com download. It is a BUILD-TO-ORDER engagement: ECOSIRE scopes your provider mix, sender-ID and country requirements, and your existing SMS touchpoints, then builds, installs, and hands over a production-ready module tuned to your Odoo database. Typical delivery is one working week depending on the number of gateways and any custom triggers you need wired in.
Architecturally the module is idiomatic Odoo. New models (sms.gateway.provider, sms.gateway.route, sms.gateway.log, sms.gateway.template) are declared with models.Model; computed fields such as live balance and rolling success rate use @api.depends; access is locked down with ir.model.access.csv plus record rules so only SMS administrators can edit credentials while agents can only read logs. Backend screens are standard XML/OWL views with a routing dashboard, and delivery reports render through QWeb. Because dispatch is intercepted at the sms.api layer, every existing SMS trigger you already use — automated actions, marketing SMS campaigns, portal OTP, sale/invoice confirmations — starts flowing through the hub with zero changes to those flows. An XML-RPC/JSON-RPC surface lets external systems queue messages into the same routing engine.
The result: provider redundancy so a single outage never silences you, least-cost routing so you stop overpaying on international traffic, and one unified template and log layer so compliance and support finally see every message in one place. Works on Odoo 17, 18, and 19, Community or Enterprise.
Ce que vous obtenez
- Complete custom Odoo module `sms_gateway_hub` (source code) compatible with your Odoo 17, 18, or 19 database, Community or Enterprise
- Seven pre-built, connected provider adapters — Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign, D7 — configured with your live credentials and sender IDs
- Configured routing engine: priority/failover order and a least-cost rate table populated for your target destination countries
- Per-country sender ID map set up and, where we can, registered/validated against each provider's requirements
- Installation and deployment onto your server or Odoo.sh, plus a smoke-tested go-live with real test sends across each gateway
- Admin documentation and a runbook: how to add a provider, edit routes, read the delivery log, and interpret failover behaviour
- A live handover training session (screen-share) for your admin and support team, with the recording
- A defined post-go-live support window for bug fixes, provider-credential adjustments, and Odoo minor-version compatibility
Pour qui c'est
Global operations / IT lead
Runs Odoo across multiple countries and cannot afford OTPs and order alerts going dark when one SMS provider throttles or has an outage. Wants provider redundancy and a single place to see every message's delivery status.
Growth / marketing manager
Sends bulk promotional and lifecycle SMS at scale and is tired of overpaying on international routes. Wants least-cost routing, scheduled campaigns with quiet-hour windows, and per-country sender IDs that actually get delivered.
Fintech / high-volume transactional sender
Depends on SMS OTP and fraud alerts where a failed message is a lost login or a security gap. Needs automatic failover, DLR-backed proof of delivery, and rate-limit-aware dispatch that keeps transactional traffic flowing.
Comment Multi-Provider SMS Gateway Hub se compare
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Natif Odoo |
|---|---|---|---|---|
| Multiple SMS providers in one system | Seven providers connected, add more anytime | Whatever you pay to build, one at a time | Usually one provider per app | Single IAP provider only |
| Automatic failover on outage or throttle | Yes — auto-retry via next healthy gateway | Only if explicitly built | Rare — no cross-provider fallback | No — message just fails |
| Least-cost routing per destination country | Yes — rate table picks cheapest eligible route | Possible but expensive to build | No | No |
| Per-country sender ID configuration | Yes — mapped and registered per destination | Depends on scope | Limited to that provider's options | Basic, single provider |
| Unified template & delivery log across providers | Yes — one log, one template layer, with DLR | You build and maintain it | Per-app, not consolidated | Basic SMS log, no routing/cost detail |
| Works on existing Odoo SMS triggers with no reconfig | Yes — intercepts at sms.api layer | Depends on implementation | Varies; often needs rewiring | N/A — it is the native trigger |
| XML-RPC / JSON-RPC access for external systems | Yes | Only if built | Rare | Generic Odoo RPC, no routing logic |
| Odoo 17 / 18 / 19, Community & Enterprise | All three versions, both editions | Whatever you target | Varies by listing | Core feature, all versions |
| Ownership, support & documented handover | Full source + runbook + support window | You own it but self-support | Vendor-locked, ticket support | Odoo standard support only |
Foire aux questions sur Multi-Provider SMS Gateway Hub
How long until it's live, and what's the process?
This is a build-to-order module, not an instant download. Typical lead time is one working week from kickoff, depending on how many gateways you use and whether you need custom triggers wired in. The process: (1) a scoping call to confirm your provider mix, target countries, and sender-ID needs; (2) ECOSIRE builds `sms_gateway_hub` against your Odoo version; (3) we install it on your server or Odoo.sh and run real test sends through each gateway; (4) go-live plus a handover training session. You never receive a half-built module — we deploy a tested, production-ready system.
What do support and updates look like after go-live?
Every engagement includes a defined post-go-live support window covering bug fixes, provider-credential adjustments, and compatibility with Odoo minor-version updates on your installed major version (17, 18, or 19). Within that window we fix defects at no extra charge. After it ends, you can move onto an ongoing ECOSIRE support and maintenance plan, or take the source code and self-maintain — the module is yours, fully commented, and documented with a runbook.
Do I need Odoo Enterprise, or does this work on Community?
It works on both Community and Enterprise, on Odoo 17, 18, and 19. The hub sits on top of Odoo's standard `sms.sms` / `sms.api` framework, which exists in Community, so you are not forced onto Enterprise. If you use Enterprise-only features like Marketing SMS campaigns, those route through the hub automatically as well.
Will my existing SMS flows keep working, or do I have to reconfigure everything?
They keep working. Because dispatch is intercepted at the `sms.api` layer, every SMS you already trigger — automated actions, portal OTP, sale/invoice confirmations, marketing SMS — starts flowing through the routing engine with no changes to those flows. You configure providers and routes once; the rest of Odoo doesn't know or care which gateway ultimately sends the message.
How does failover and least-cost routing actually decide which provider to use?
For each message, the routing engine matches the destination country/prefix against your `sms.gateway.route` rate table to find eligible providers, then picks by your chosen strategy — lowest cost, or strict priority. If the selected gateway errors, times out, or is out of balance, the message is automatically retried through the next healthy provider. Every decision (chosen provider, route, unit cost, and any failover) is written to the delivery log so you can audit exactly what happened.
Can other systems send SMS through the hub, not just Odoo?
Yes. The module exposes an XML-RPC / JSON-RPC endpoint so external applications — or a second Odoo instance — can enqueue messages into the same routing engine. They get the same failover, least-cost routing, and unified logging without needing to integrate with any individual provider's API directly.
Can you add a provider that isn't in the default seven?
Yes. The provider layer is deliberately pluggable — each gateway is an independent adapter record. If you need a regional aggregator or an in-house SMPP route in addition to Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign, and D7, we scope and build that adapter as part of the engagement or as a follow-up. Tell us during scoping and we'll price it in.
Modules associés
Multi-CRM Connector Hub
One Odoo connector to sync CRM leads, contacts & deals with HubSpot, Salesforce, Pipedrive, Zoho, Vtiger and Intercom.
Multi-Currency Financial Reports
See P&L, Balance Sheet, Trial Balance and ledgers in any active currency with date-specific FX rates. Built, installed and supported by ECOSIRE.
MyFatoorah Payment Gateway for Odoo
One MyFatoorah connector for all GCC methods — KNET, mada, Benefit, cards, Apple Pay. Built-to-order for Odoo 17/18/19 by ECOSIRE.
Netvisor Connector for Finland
A build-to-order integration that keeps Odoo and your Finnish accounting system reconciled — pushing invoices, importing bills and payments, and mapping the GL and cost centres both ways. ECOSIRE scopes, builds, installs and supports it after you request a quotation.
Multi-Provider SMS Gateway Hub
One Odoo SMS framework routing through Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign & D7 with failover and least-cost routing.
- Pluggable provider framework — each gateway (Twilio, Vonage, Plivo, MessageBird, Telnyx, TeleSign, D7) is a self-contained `sms.gateway.provider` record with its own REST adapter, so new providers drop in without touching core dispatch code
- Automatic failover: if the primary gateway returns an error, times out, or its balance hits zero, the routing engine retries the same message through the next healthy provider in priority order
- Least-cost routing — a `sms.gateway.route` rate table matches the destination country/prefix and selects the cheapest eligible provider per message, logging the chosen route and unit cost
- Per-country sender ID configuration: alphanumeric or numeric sender IDs mapped by destination (e.g. branded ID for UAE, long code for US) to satisfy each country's registration rules