Skip to main content

Phone Lookup: LoopLookup

Purpose​

Phone Lookup: LoopLookup adds a Loop Lookup page to SMS Inbox records. It submits a phone number to the external lookup service, stores the result and timestamp, and can accept asynchronous result callbacks. It enriches the inbox; it does not send an SMS, provision an iMessage account or guarantee message delivery.

Before you start​

Install corvus_sms_loop_lookup with corvus_sms_inbound for the same Odoo major version. No Enterprise-only dependency is declared. Use an existing authorised LoopLookup account and key. Lookup actions disclose the selected phone number to that provider and can consume its service allowance. This guide reviews 19.0 source; no lookup, callback or runtime test was performed.

Access and roles​

The addon creates no new access group or standalone menu. Inbox access comes from Two-Way SMS & CRM Inbox: internal users can read, create and edit inbox records; Settings administrators have full access. Configuration appears inside the dependency's SMS Routing Settings app, which is restricted to Access Rights administrators (base.group_erp_manager). An administrator should verify operator and callback access in the installed package before enabling automatic lookup.

Setup and menu​

Open Settings → SMS Routing → Loop Lookup. Configure Loop Lookup API Key, Auto Loop Lookup, Lookup Freshness (days), Lookup API URL, and Webhook Token. Auto lookup defaults off; freshness defaults to 30 days. The source default URL is https://a.looplookup.com/api/v1/lookup/.

The request uses an Authorization header containing the configured key and a JSON contact field holding the normalised phone. Treat the API key and callback token as secrets. An administrator must configure a nonempty Webhook Token before enabling an external callback. The callback address is the Odoo base address plus /looplookup/webhook; it accepts POST, with the matching token supplied in the X-Lookup-Token header or the documented payload token field. Do not expose an unvalidated callback to live traffic.

Workflow​

  1. Open Discuss → SMS Inbox, choose the correct conversation and check its normalised phone/contact. The lookup target prefers inbox phone values before the contact's mobile/phone fallback.
  2. Open Loop Lookup and inspect Latest Result, Lookup Audit and Provider Payload. A timestamp is needed to judge freshness; an old result does not establish the number's current capabilities.
  3. When an external query is authorised, choose Check Loop Lookup Now. This forces a new request even if automatic lookup is off or the cached value is fresh.
  4. Review Loop Lookup Status, Loop Lookup Checked At and Loop Lookup Phone. An immediate Submitted result can precede a later callback; it is not a completed device classification.
  5. If the provider returns a final asynchronous result, the source matches its contact number to inboxes and updates stored capability/status fields. An unmatched number can create an unlinked inbox, so callback handling belongs in the administrator's configuration review.
  6. If Auto Loop Lookup is enabled, compatible SMS composer integration requests refresh when the number changes, no prior check exists or the configured freshness period expires. This addon does not install an independent periodic lookup scheduler.

Practice scenario​

Use the fictional inbox Linden Workshop, +12025550123, in an authorised training database. Review the target phone and freshness settings with automatic lookup disabled. Describe how a cached result dated more than 30 days ago would be considered stale without pressing Check Loop Lookup Now. This source-derived exercise was not executed and sends no lookup request.

Troubleshooting and limitations​

Phone number is required for Loop Lookup or No phone/mobile number to check means the inbox/contact lacks a usable number. Loop Lookup API key is not configured requires administrator setup. Request failures are stored in status with a check timestamp; use a deliberate manual retry after resolving the cause, since automatic freshness logic can otherwise retain the recent failed check.

The stored iPhone flag is inferred from provider fields such as device or Apple-service availability. It is a provider classification, not verified hardware identity, consent, reachability or guaranteed iMessage routing. Read the full status and payload for context. The callback acknowledgement does not independently prove that the intended inbox was updated.

Catalogue-qualified versions are 17.0–20.0. The 19.0 workflow is source-reviewed. Selected 17.0/18.0 comparisons use the older JSON controller route type; 20.0 changes configuration accessors. Full alternate-version workflows remain unverified.

Choose the exact package and available Live Test selector through the Corvus app catalogue. No demo was launched. See Two-Way SMS & CRM Inbox and SMS Inbox & Composer for the surrounding workflow.