Popl and iMessage: getting leads to the right rep’s line

The short answer

Popl does not have an iMessage API. It holds no phone number, sends no messages, receives no replies, and reports no delivery outcomes. As of August 27, 2026 its published documentation covers card management, lead capture, and integrations — not a messaging channel.

Its export surface is strong, though, and unusually well suited to team structures. That turns out to matter for the workflow people are actually trying to build.

What Popl gives developers

Popl’s integration surface centers on getting captured leads into other systems. Leads captured via Popl flow into HubSpot directly, and its Zapier app syncs lead and contact information to thousands of CRM and marketing platforms. Where no integration exists, Popl’s documentation describes building your own against its API.

The detail worth noticing is the trigger granularity. Popl’s Zapier app exposes a New Lead event for your team, firing whenever anyone on the team captures a lead, and a New Lead event for a subteam, firing for a specific group of members. Most platforms in this category expose only an account-level trigger.

• Native HubSpot integration for captured leads
• Zapier app covering thousands of CRM and marketing destinations
• New Lead (For Your Team) trigger — any team member’s capture
• New Lead (For Your Subteam) trigger — a specific group
• API documentation for building a custom integration
• Contact enrichment through tools such as ZoomInfo
• No line, no send endpoint, no inbound message events

Why people expect a messaging product here

Popl is the most consumer-visible brand in the category — NFC cards, a wide hardware range, strong customization — and visible brands attract feature assumptions. If it can capture a lead and push it to HubSpot, sending a text feels like the obvious next feature.

It is not, and the reason is structural. Messaging means Apple accounts, hardware, deliverability, and an on-call operations team. Linq is the one company in this category that took that on, launching Linq Blue as a separate messaging product with an iMessage API — which is why the assumption keeps surfacing for its competitors.

Subteam triggers solve the routing problem

Here is where Popl’s structure earns its keep. In a team deployment, the follow-up text should usually come from the rep who actually met the person — or at least from a line associated with their region or their product. A single company-wide number that texts every lead is worse than it sounds: the prospect replies, and the reply lands nowhere near the person who had the conversation.

Popl’s subteam-level trigger lets you route at the source. Map each subteam to a line, fire that subteam’s trigger into the workflow bound to that line, and the reply arrives in the inbox of the people who were at the booth.

• Map each subteam to a messaging line, not to one shared number
• Include the capturing member in the payload you pass through
• Put the rep’s name in the message — they met a person, not a company
• Route inbound replies to the same subteam’s inbox
• Keep an escalation path when the original rep is unavailable

A worked example in Python

Whether the lead arrives from Zapier or from Popl’s API directly, the shape on your side is the same: resolve which line to send from, check consent and suppression, then send with an idempotency key derived from the Popl lead identifier.

Resolve the line from the subteam rather than hard-coding one. That single indirection is what keeps the workflow usable as the team grows past one region.

import os
import httpx

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

# Each subteam sends from — and receives replies on — its own line.
LINE_BY_SUBTEAM = {
    "west": os.environ["MISS_BLUE_LINE_WEST"],
    "east": os.environ["MISS_BLUE_LINE_EAST"],
}

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

    rep = lead.get("captured_by_name", "our team")
    response = httpx.post(
        f"{BASE}/v1/messages",
        headers={
            "Authorization": f"Bearer {os.environ['MISS_BLUE_KEY']}",
            "Idempotency-Key": f"popl:{lead['id']}",
        },
        json={
            "number_id": number_id,
            "recipient": recipient,
            "text": (
                f"Hi {lead['first_name']}, it's {rep} — we spoke at the booth today. "
                "Sending over what I promised; reply here anytime."
            ),
        },
        timeout=httpx.Timeout(15.0, connect=3.05),
    )
    response.raise_for_status()
    return response.json()

Enrichment does not create consent

Popl’s ecosystem includes contact enrichment through tools such as ZoomInfo. Enrichment is useful for CRM completeness and it is a trap for messaging: a phone number appended from a data provider is not a number the person gave you, and texting it is a different act from texting a number somebody typed into your capture form.

Keep enriched fields flagged and out of the messaging path unless you have separate, recorded consent covering them. Send only to numbers a person supplied directly, and store which field the number came from so the distinction survives into your CRM.

Consent at capture

Accepting a Popl card means accepting contact details. It does not mean agreeing to receive business text messages, and the gap between those two is where complaints originate. 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 opt-in on the capture form, record the timestamp and the exact wording with the lead, and carry it through Zapier or the API into the messaging system. One field at capture is far cheaper than reconstructing consent for a list you already collected.

• Opt-in on the capture form itself
• Store source, timestamp, and wording with the lead
• Never message an enriched number without separate consent
• Suppress across every subteam workflow at once
• Name the rep in the first message

What about RCS?

Popl publishes no RCS API either. Channel selection belongs on the messaging provider’s side, where a decision can be made per recipient based on what their device and carrier support.

Design for that: pass the contact through to your messaging provider and let it choose, rather than trying to segment Apple and Android contacts inside the card platform.

A build order

Start with one subteam. Routing bugs are much easier to see when there are two lines than when there are twelve, and the consent and dedup work is identical at either scale.

Expand once you have watched a full cycle — capture, send, reply, handoff — for a real event or a real week of field work.

• Add a messaging consent field to the Popl capture form
• Wire the subteam trigger for one subteam into a queue
• Map that subteam to a dedicated line
• Send with an idempotency key derived from the Popl lead id
• Route replies to that subteam’s shared inbox and staff it
• Measure replies, qualified conversations, and opt-outs, then add subteams

The messaging half

Miss Blue provides the part Popl does not: dedicated business iMessage lines, an HTTP API with signed webhooks and durable conversation events, and a shared Message Center where a subteam works its own threads and can take over from an automation mid-conversation.

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. In a subteam-per-line design, the line count is what drives the bill — model it before you roll out.