There is a persistent cluster of searches pairing digital business card companies with "iMessage API": Blinq, Popl, Mobilo, HiHello, Switchit, sometimes with a language attached — "Blinq iMessage API Node.js", "Mobilo iMessage API Python". The volume is real. The products, for the most part, are not.
Where the confusion comes from
Linq — linqapp.com — is a digital business card company that genuinely pivoted into communications infrastructure. It now sells an iMessage, RCS, SMS and voice API, marketed heavily, and is a real vendor in this category. We have written it up separately.
Linq's direct competitors are Blinq, Popl, Mobilo, HiHello and Switchit. Once one company in a competitive set launches a product, comparison content, keyword tools and AI-generated round-ups start pairing every other name in that set with the same product — whether or not it exists. That is the mechanism producing these searches, and it is why the phrasing is so formulaic.
What we checked, and what we found
As of August 2026 we found no public evidence that Blinq, Popl, Mobilo, HiHello or Switchit offer an iMessage API. Their public integration stories are contact-sync and CRM connectors — Salesforce, HubSpot, Dynamics, Pipedrive, Zoho, Outlook — which is a different thing entirely. Absence of public evidence is not proof; if you need certainty, ask the vendor directly.
Contact-sync APIs are not messaging APIs
All of these companies do have APIs. They are for pushing a captured contact into your CRM after a card exchange. That is a genuinely useful thing and it is not what you are looking for if you searched for an iMessage API — it moves a record, it does not send a message to a phone.
| What their API does | What an iMessage API does |
|---|---|
| Creates a contact record from a card tap | Sends a message to a phone number |
| Syncs that contact to Salesforce or HubSpot | Receives the reply through a webhook |
| Reports on card views and shares | Reports delivery and read status |
| Usually gated to enterprise plans | Usually starts at a free sandbox |
If you got here from a card app
The underlying job is usually the same: someone scanned your card, you have their number, and you want the follow-up to arrive as a blue bubble instead of an ignorable green one. That is a real workflow and it is well served — just not by the card vendor.
- Keep the card app for capture and sync. It is good at that.
- Pick an iMessage provider for the messaging. The comparison is here, the prices are here.
- Connect them through your CRM rather than directly — the card app already writes to it. How to wire that up.
- Send the follow-up within the hour, while they remember meeting you. Speed is most of the effect.
Dana Reyes
iMessage
Dana — Chris from the Thursday panel. Sending the deployment numbers I mentioned: chrisatlas.co/notes. Happy to walk through it next week if useful.
Perfect, thanks Chris. Tuesday works
The general lesson
This category attracts a lot of generated comparison content, and brand-plus-feature searches that no product matches are one of the visible symptoms. It is worth applying the same scepticism to any vendor claim you meet here — including the ones on this site, which is why we say where each number came from and when we checked it.
If a vendor genuinely has an iMessage API, they will have a documentation site, an endpoint you can curl, and usually a sandbox. If searching their own domain for "iMessage" returns nothing, that is your answer. What a real one looks like on paper.