Two-Way SMS & CRM Inbox
Purpose
Two-Way SMS & CRM Inbox connects inbound provider webhooks to Odoo conversations. It normalises numbers, matches contacts and business records, applies a routing policy and maintains inbox history. It also adds sender numbers, usage limits, payload parsing and inbound processing logs to the gateway foundation.
Before you start
Install corvus_sms_inbound with eis_sms_apis, mail, crm and web for the same major version. No Enterprise-only dependency is declared. An existing provider must support inbound callbacks, and an administrator must configure an externally reachable Odoo address and authorised sender numbers. This guide reviews 19.0 source; no runtime or provider webhook test was performed.
Access and roles
Settings administrators (base.group_system) manage gateway numbers, inbound logs and send-guard records. Internal users (base.group_user) can read sender-number records and read, create and edit inboxes, but cannot delete inbox records through that ACL. Settings administrators have full inbox access. The payload-parser wizard grants access to Settings administrators and Access Rights administrators (base.group_erp_manager); its gateway button is shown to the latter group. The SMS Routing Settings app is also restricted to base.group_erp_manager.
Configure each operator's sender assignments explicitly and have an administrator verify the intended access in the installed package. Inbox access is not described here as isolation by salesperson, team or company; the module does not define those inbox record rules.
Setup and menu
Open SMS Gateways, then the required gateway. On Gateway Numbers, add the Number, label, sequence, country prefixes, Default, Allowed Users, Hourly Limit and Daily Limit. A zero limit means unlimited. User and company forms add Default SMS Sender Number; SMS Routing → Global Fallback supplies a further default. The default-number helper checks user, company and global candidates in that order before other active numbers.
Enable Supports Inbound. Under Inbound Webhook, configure:
| Control | Purpose |
|---|---|
| Inbound Callback URL / Regenerate Token | Token-bearing callback endpoint; regeneration changes the URL that the provider must use. |
| Inbound From / To / Text / Media / Message ID Param | Map the provider payload. Nested paths such as data.payload.from.phone_number and array paths are supported. |
| Use Inbound URL for Delivery Callbacks | Reuse reception URL for delivery events; requires careful event classification. |
| Webhook Alert Param, Inbound Alert Values, Status Alert Values | Distinguish incoming messages from delivery reports. |
| Webhook ID Param / Inbound Idempotency | Identify repeated events; default deduplication window is 120 minutes when enabled. |
| Verify Webhook Signature | Optional HMAC validation using configured header, secret, algorithm, prefix and payload mode. |
Signature algorithms offered are SHA256 or SHA1, each in hex or base64. Payload mode is Raw Body or timestamp.raw. Optional timestamp freshness uses Timestamp Header and Max Signature Age (Seconds), default 300. Match these fields to the actual provider signing method; the presence of HMAC options does not establish compatibility with every provider signature scheme. Keep callback tokens and signature secrets private.
In Settings → SMS Routing, choose Primary Target, Fallback Target, Lead Strategy, and the missing-record actions. Primary choices are Last Outbound Document, CRM Lead, Contact (Partner) or SMS Inbox Only. Defaults favour the last outbound document with a contact fallback. Missing-record options can create contacts/leads or discard to logs, so review them before connecting an active webhook.
Workflow
- Prepare the gateway mappings and sender numbers, then open Test Payload Parser. Enter a synthetic Payload JSON and optional Headers JSON. Run the parser and inspect Parse Result. It previews extracted values, classification, signature and duplicate information; it does not deliver an SMS or prove that the live provider can reach Odoo.
- Check that sender, recipient, text and provider ID resolve as expected. Correct field paths before enabling reception. Delivery reports must classify as status events rather than new enquiries.
- Have the implementation administrator configure the provider to use the displayed Inbound Callback URL after validating the gateway and routing policy.
- For an actual incoming event, the source looks up or creates the configured contact/lead target and posts a conversation message. It also attempts to maintain an inbox conversation, subject to the unlinked-contact policy.
- Open Discuss → SMS Inbox, then the conversation. Review Total SMS, Unread, phone/contact and latest message. Use the companion SMS Inbox & Composer for the richer reply composer.
- Administrators inspect Inbound Logs when an event is absent or ambiguous. Review status, processing note, provider ID and duplicate markers. A webhook HTTP acknowledgement alone does not mean routing or delivery-status correlation succeeded.
Practice scenario
For a fictional enquiry from +12025550123 to a training sender +12025550124, preview {"from":"+12025550123","to":"+12025550124","message":"Please send the sample catalogue","id":"training-001"}. Check the extracted values without posting to a live callback. Discuss whether the intended policy should create a lead or keep an unlinked inbox. This source-derived exercise was not executed.
Troubleshooting and limitations
Missing sender numbers can produce Inbound ignored: missing from_number. Discard rules and disabled unlinked-inbox handling may intentionally prevent a conversation. Invalid signature requires checking payload bytes, algorithm, headers and timestamp agreement; do not simply turn verification off to suppress an error. Repeated provider deliveries need idempotency configured deliberately; it is disabled by default.
Number matching includes normalisation and fallback comparisons; use complete international numbers and review ambiguous matches. Sender limits are simple application counters, not a guarantee of provider rate-limit compliance. Routing may create business records, and installed companion modules may also trigger email or translation actions.
Versions and useful links
Catalogue-qualified versions are 17.0–20.0. The 19.0 workflow is source-reviewed. Selected comparisons show 17.0 uses older tree views and mail serialisation, while 20.0 changes configuration reads, access declarations and mail/bus interfaces. Other version workflows remain unverified.
Use the Corvus app catalogue to choose the exact version and available Live Test selector; no demo was launched. Related guides: SMS Gateway & API Routing, MMS Media & Attachments, and SMS & MMS Messaging Suite.