Mobilo and iMessage: routing lead capture into a text

The short answer

Mobilo does not have an iMessage API. It holds no phone number, sends nothing, receives no replies, and reports no delivery state. As of August 27, 2026 its published documentation describes lead capture and routing, not a messaging channel.

What it does have is a genuinely capable export surface — an API key, webhooks, and a Zapier trigger that fires on new leads. That is the half of the workflow Mobilo is good at. The send has to come from somewhere else.

What Mobilo actually gives developers

Mobilo positions itself around speed and high-volume lead capture for sales teams, exhibitors, and event professionals, and its integration surface reflects that priority. You retrieve your API and account key from the API and Automation Settings page in the account menu.

From there, contacts move out through webhooks, direct API calls, or Zapier, into HubSpot, Salesforce, Pipedrive, Zoho, Microsoft Dynamics, and the rest of the Zapier catalog. The Zapier trigger fires when a new lead is created on your account.

• API and account key from API and Automation Settings
• Webhooks for lead events
• Zapier trigger on new lead created
• CRM push to HubSpot, Salesforce, Pipedrive, Zoho, Dynamics, and more
• NFC card tap and QR scan as the capture mechanism
• No line, no send endpoint, no inbound message events

Why the assumption is reasonable

Mobilo is sold as sales automation, and sales automation in most other categories includes outbound messaging. It is a short step from “routes leads into pipelines and triggers follow-up tasks” to “sends the follow-up”, but that step is the one Mobilo does not take.

The other source of the confusion is Linq — a digital business card company in the same category that launched Linq Blue, a separate messaging product with an iMessage API. One vendor crossed over; the reasonable inference is that others did too. They have not.

Event day is the real design constraint

This is what makes Mobilo integrations different from the rest of the category. Mobilo is built for booth traffic, and booth traffic is bursty: a trade show generates in an afternoon what a normal month generates in total. Your messaging design has to survive that shape, not the average.

Two things break under burst. First, per-line pacing — messaging providers publish daily new-conversation limits, and four hundred captures in six hours will exceed a single line’s sensible pace regardless of what the plan permits. Second, staffing — every one of those texts can be replied to, and a burst of outbound produces a burst of inbound roughly twenty minutes later.

• Model the peak hour, not the daily average
• Spread sends across the event rather than firing the whole list at close
• Add lines for legitimate capacity rather than pushing one line harder
• Staff replies during and after the event, not the next morning
• Queue the sends — never fan out straight from the webhook handler

A worked example in Python

Mobilo’s webhook or Zapier step lands a lead on your side. Enqueue it rather than sending inline: the handler should acknowledge fast and let a worker do the send with retries, so a slow provider call cannot cause Mobilo to retry the delivery and produce a duplicate.

Derive the idempotency key from the Mobilo lead identifier. A redelivered webhook then becomes a no-op rather than a second text to someone who tapped a card once.

import os
import httpx

BASE = "https://api.missblue.dev"

def send_follow_up(lead: dict) -> dict | None:
    recipient = to_e164(lead.get("phone"))
    if not recipient or is_suppressed(recipient):
        return None
    if not has_messaging_consent(lead["id"]):
        return None

    response = httpx.post(
        f"{BASE}/v1/messages",
        headers={
            "Authorization": f"Bearer {os.environ['MISS_BLUE_KEY']}",
            # Keyed on the Mobilo lead, so a redelivered webhook is a no-op.
            "Idempotency-Key": f"mobilo:{lead['id']}",
        },
        json={
            "number_id": os.environ["MISS_BLUE_NUMBER_ID"],
            "recipient": recipient,
            "text": (
                f"Hi {lead['first_name']} — great chatting at booth 412. "
                "Sending the spec sheet over now; reply here if you want a demo slot."
            ),
        },
        timeout=httpx.Timeout(15.0, connect=3.05),
    )
    response.raise_for_status()
    return response.json()

Deduplicate before you send, not after

Booth capture produces duplicates at a rate other channels do not. The same person taps two reps’ cards, or scans and then fills the form, or comes back on day two. Mobilo will faithfully report each as a lead event because each one happened.

Deduplicate on the normalized phone number across the whole event, not per lead event. Otherwise the most interested prospect at the show — the one who came back twice — receives the most messages, which is precisely backwards.

Consent at the capture form

Someone tapping a Mobilo card has agreed to receive contact details. That is not agreement to receive business texts, and a busy booth is exactly where this distinction gets skipped. CTIA’s Messaging Principles set the industry expectation of consent before messaging and a working opt-out, and applicable law may be stricter for promotional content.

Put the messaging opt-in on the Mobilo capture form and store the timestamp and wording with the lead. At an event this is also practical protection: a scanned badge list and a consented messaging list are different things, and only one of them is safe to text.

• Opt-in lives on the capture form, checked at the booth
• Store source, timestamp, and exact wording with the lead
• A scanned badge is not a messaging opt-in
• Suppress across every workflow at once
• Identify the business in the first message

iMessage or RCS?

Mobilo publishes no RCS API either — the question of which channel a given contact receives belongs on the messaging side, where a provider can pick per recipient based on what the destination supports.

At an event with mixed devices this matters more than usual. Design the workflow so the channel decision happens after the contact reaches your messaging provider, rather than trying to segment Apple and Android contacts inside the card platform.

A build order for the first event

Do not debut this at your biggest show. Run it at a small one, or with two reps at a large one, and expand once the numbers behave.

Each step below catches something the previous one cannot, and the ones people skip are deduplication and reply staffing — the two that only fail at volume.

• Add a messaging consent field to the Mobilo capture form
• Wire the webhook or Zapier trigger into a queue, not a direct send
• Normalize and deduplicate on phone number across the whole event
• Send from a dedicated line with an idempotency key and paced throughput
• Route replies into a shared inbox staffed during show hours
• Review reply rate, qualified conversations, and opt-outs before the next event

The messaging half

Miss Blue provides what Mobilo does not: a dedicated business iMessage line, an HTTP API with signed webhooks and durable conversation events, and a shared Message Center where several teammates can work the inbound burst together and take over threads an automation started.

Published pricing is $39 per month for a shared testing number and $99 per month per dedicated number, with unlimited commercial usage, contacts, team access, the Message Center, and API access included on the dedicated plan. Those are current 50%-off sale rates against regular prices of $78 and $198, locked in while the plan remains active. For event work, price the number of lines your peak hour needs rather than your monthly average.