Blinq and iMessage: what the API actually does

The short answer

Blinq does not have an iMessage API. It does not hold a phone number, compose messages, receive replies, or report delivery outcomes, and no plan tier adds those capabilities. As of August 27, 2026 nothing in Blinq’s published documentation describes a messaging channel of any kind.

What Blinq does publish is a developer surface for the product it actually sells: creating and managing digital business cards across an organization, and getting captured contacts back out. That is contact plumbing, and it is genuinely useful — it is just the first half of what you are trying to build.

What Blinq’s developer surface covers

Blinq is positioned at the enterprise end of the digital business card category, and its API reflects that. The published enterprise capabilities center on provisioning and identity rather than on outbound communication.

Blinq’s technical documentation lives at docs.blinq.me and covers connecting CRM, marketing, and HR platforms. Read the verbs there: it provisions, updates, syncs, and exports. It does not send.

• Bulk card creation via API across a team
• Contact export via webhooks
• SAML SSO with Microsoft Entra ID, Azure AD, Active Directory, and Okta
• SCIM provisioning, so directory changes propagate automatically
• CRM integrations including Salesforce, HubSpot, and Microsoft Dynamics
• Custom analytics and admin controls

The enterprise gate is the practical obstacle

This is the detail that stalls most Blinq integrations. Blinq’s published materials place bulk card creation via API and contact export via webhooks in an enterprise solution described for teams of 500 or more, and its Salesforce, HubSpot, and Dynamics integrations are described as requiring an Enterprise subscription and activation by special request.

So if you are on a smaller plan and reading the integrations page, confirm what your specific tier exposes before designing anything around webhooks. A team of thirty reps may find that the real available path is a manual export or a connector rather than the enterprise webhook the marketing page describes.

• Confirm whether webhook-on-capture is enabled for your tier
• Confirm whether your CRM integration needs special-request activation
• Ask what the fallback is below Enterprise — export, connector, or nothing
• Check rate limits on whatever export path you land on

Why people expect Blinq to have one

The assumption is reasonable, and it traces to one company. Linq is a digital business card platform in the same category as Blinq, and Linq launched Linq Blue — a separate messaging product with an iMessage API. The names are similar enough to compound the confusion.

Linq is the exception, not the pattern. Messaging infrastructure means Apple accounts, hardware, deliverability, throttling, and an operations team on call. It is a different business from contact exchange, and Blinq has stayed in the business it is in.

What you are actually trying to build

The workflow behind this search is almost always the same. A rep taps a Blinq card at a conference or a site visit. A contact record appears. Somebody wants that person to receive a text within the hour — from a real number, in a blue bubble, that they can reply to.

It is a strong workflow because the follow-up is expected: the recipient met you minutes ago. It needs two products. Blinq owns the capture and the identity plumbing; a messaging provider owns the line, the send, and the reply.

Getting contacts out of Blinq

Take the highest option on this list that your plan supports. Latency matters here more than in most integrations — a follow-up that arrives while someone is still at the event outperforms one that arrives the next morning.

Whatever path you use, normalize the phone number to a single canonical format at the boundary. Card capture forms return numbers exactly as typed, and two formats of one number becomes two conversations, two consent records, and eventually two texts to the same person about the same thing.

• Contact-export webhook on Enterprise — fires at capture, lowest latency
• CRM as the join — let Blinq sync to Salesforce or HubSpot, then trigger messaging off the CRM record
• Scheduled export — simplest, slowest, acceptable for next-morning follow-up

A worked example in Node

Once a contact reaches your server, the messaging half is one authenticated POST. Verify the incoming payload against whatever signing your export path provides, normalize the number, check consent, and send with an idempotency key derived from the capture event rather than generated fresh.

That last detail matters because card platforms redeliver. A retried webhook with a fresh key produces a second text to somebody who just met your rep, which is exactly the impression this workflow exists to avoid.

// After a Blinq contact-export webhook reaches your handler.
const BASE = "https://api.missblue.dev";

export async function followUp(contact, captureEventId) {
  const recipient = toE164(contact.phone);          // normalize first
  if (!recipient) return;                            // no number, no send
  if (await isSuppressed(recipient)) return;         // opt-outs win
  if (!(await hasMessagingConsent(captureEventId))) return;

  const response = await fetch(`${BASE}/v1/messages`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.MISS_BLUE_KEY}`,
      "Content-Type": "application/json",
      // Derived from the capture event, so a redelivered webhook is a no-op.
      "Idempotency-Key": `blinq:${captureEventId}`,
    },
    body: JSON.stringify({
      number_id: process.env.MISS_BLUE_NUMBER_ID,
      recipient,
      text: `Great meeting you at the booth, ${contact.firstName}. Here is the pricing sheet I mentioned — happy to answer anything.`,
    }),
    signal: AbortSignal.timeout(15_000),
  });

  if (!response.ok) throw new Error(await response.text());
  return response.json();
}

Consent is where this goes wrong

Someone accepting your Blinq card has agreed to receive your contact details. They have not agreed to receive business text messages. Treating a card scan as blanket messaging consent is the specific mistake this workflow invites, and it is the one that produces complaints.

Fix it at capture. Put a messaging opt-in on the Blinq capture form itself, store the timestamp and the exact wording alongside the contact, and carry that record into the messaging system. Retrofitting consent onto contacts you have already collected is far harder than adding one field to a form. 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.

• Add the opt-in to the capture form, not to a later email
• Store source, timestamp, and wording with the contact
• Keep transactional and promotional consent separate
• Suppress across every workflow at once, not per campaign
• Identify the business in the first message — they met a person

What about RCS?

Some searches pair Blinq with RCS rather than iMessage. The answer is the same: Blinq does not publish an RCS API either, and RCS carries its own carrier registration and campaign requirements that a contact-exchange product has no reason to take on.

If you need to reach both Apple and Android contacts from one workflow, that belongs on the messaging side of the architecture, where a provider can decide the channel per recipient. Blinq’s job in that design is unchanged: give you a clean, consented contact record.

The rest of the category answers the same way

Blinq is not unusual here. The same question is asked of every platform in the category, and as of August 27, 2026 the answer is the same for all of them: contact exchange, not messaging. Only one vendor crossed over.

If you are evaluating more than one card platform, the messaging half of your architecture is unaffected by which you pick — so choose on capture, provisioning, and CRM fit, and treat the line as a separate decision.

• Blinq — enterprise provisioning, SSO and SCIM, contact export webhooks
• Popl — NFC hardware range, with team and subteam lead triggers
• Mobilo — high-volume event lead capture, API key and Zapier trigger
• HiHello — a contact manager first, with multiple profiles and a directory
• Switchit — video-first cards, shared by text from your own device
• Linq — the same category, plus Linq Blue, a separate messaging product with an API

Choosing the messaging side

The second product is a business messaging line with an API, and the evaluation is the ordinary one for that category. The questions below separate a line you can build a workflow on from one that only demonstrates well.

Weigh human takeover more heavily than you might expect. A card scan produces a warm contact who often replies with something specific, and an automation that cannot hand off gracefully wastes exactly the leads this workflow exists to capture.

• A dedicated line you own, not a shared number
• Permission to send first, confirmed in writing
• Signed webhooks for replies and delivery outcomes
• Idempotent sends, so a retried capture event is not a duplicate text
• A shared inbox where a teammate can take the conversation over
• Suppression and opt-out handling built in
• Number ownership and data export at cancellation

A build order that works

Ship in this sequence. Each step surfaces something the previous one could not, and the whole integration is a few days rather than a project.

Run one event or one rep before connecting the whole team. The failures worth finding — duplicate captures, an unexpected number format, a reply nobody was watching — all appear within the first fifty contacts.

• Add a messaging consent field to the Blinq capture form
• Confirm which export path your tier actually supports
• Normalize numbers and deduplicate against existing contacts
• Send one templated follow-up from a dedicated line, with an idempotency key
• Receive replies into a shared inbox and staff it during event hours
• Measure replies, qualified conversations, and opt-outs before scaling

The messaging half

Miss Blue supplies what Blinq does not: a dedicated business iMessage line, an HTTP API with signed webhooks and durable conversation events, and a shared Message Center where teammates read the same thread and take over from an automation. It does not make business cards and is not a Blinq replacement — the two sit on either side of the contact record.

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.