Name: Linq
Brand: Linq
Rating: 4.8 (555 reviews)

Published Oct 15, 2026

01Common complaints

- If the primary requirement is high-volume SMS blasting - The vendor's documented rate limits and messaging platform constraints make it less suitable for high-volume marketing blasts; traditional SMS providers with A2P tooling may be preferable. - If the buyer requires fully self-serve published pricing - Public materials reviewed do not include detailed published price sheets; buyers requiring predictable published rate cards may prefer competitors with transparent pricing. - If procurement is relying on digital business card reviews to evaluate the messaging API - Reviews for the digital business card product do not necessarily reflect the API's reliability, support, or pricing model; obtain API-specific references. - If procurement requires publicly documented certifications beyond SOC 2 - ISO certifications, HIPAA, PCI DSS, and data residency options were not documented in the public materials reviewed; this can impede deals in regulated industries. - If a low-risk trial and flexible refund policy are required - Community anecdotes describe a disputed refund scenario; buyers should confirm trial terms, cancellation policies, and SLA remedies in contract negotiations. - Vendor-acknowledged limitations - Rate limits are documented by the vendor and presented as protections for platform ecosystems; these limits can restrict high fan-out messaging patterns. - The V2 API is labeled as legacy; new integrations should use the current API version (V3), which implies migration considerations for existing users. - Roadmap visibility - No public roadmap with delivery dates was found in the materials reviewed. - Scale and operational limits - Vendor marketing includes availability and latency figures; independent historical uptime and latency data were not located in public sources. - Security and compliance gaps - Beyond the SOC 2 reference, additional certifications (ISO, HIPAA, PCI) and data residency options were not publicly documented in the materials reviewed. - API integration constraints - Attachments are served from a vendor CDN and short-lived signed URLs are part of the design; allowlisting and re-fetch logic are operational considerations for some environments. - Retention policies vary by message type; ephemeral messages have short retention configured in product controls.

Deal disqualifiers

Requirement for fully transparent, self-serve pricing without sales engagement.
High-volume broadcast/marketing use cases that conflict with rate limits and platform rules.
Need for publicly documented certifications or data residency options beyond the vendor's SOC 2 claim.

02Why they buy

- Unified iMessage + RCS + SMS API with protocol fallback - The vendor documents automatic selection among iMessage, RCS, and SMS channels, which can simplify implementation compared with integrating multiple providers separately. - Native messaging capabilities for richer conversational UX - The product supports message features commonly associated with native messaging platforms (reactions, voice notes, rich media, group chat constructs) as part of its API design. - Product controls for ephemeral or sensitive content - The API provides options such as ephemeral message retention (short retention for specific message types) and short-lived signed URLs for attachments to limit persistent storage of sensitive content. - Balanced view: competitor advantages - Providers such as Twilio offer transparent published usage pricing and a broad CPaaS ecosystem; digital business card competitors may offer simpler plans for individual users.

03Field reports

- Important context for review interpretation - Many online reviews and review platform listings relate to the vendor's digital business card product rather than the messaging API product. This distinction is important for procurement: digital business card reviews may not reflect the reliability, support, or pricing model of the messaging API. - Review platforms (G2) - Reviews for the digital business card product show generally positive ratings and often mention ease of use and convenience for contact sharing. Reviewer volume on review platforms primarily reflects the business card product rather than the API. - Note on review sourcing: certain review collections are produced via vendor-invited solicitations, which can influence the composition of review sets compared with fully organic review samples. - App store reviews - Public app store review snippets indicate positive sentiment among some users of the mobile product, though individual reviews are brief and may be influenced by in-app prompts. - Community/Social (Reddit) — mixed and operationally specific - Price sensitivity and perceived forced bundling have been raised by users evaluating the digital business card product. - Some users compared the vendor to other digital business card solutions and reported switching providers due to usability or role-management preferences. - There are community complaints alleging severe operational issues in specific workflows; these are anecdotal and should be validated through vendor references and technical due diligence. - Why customers chose the vendor (inferred from reviews/discussions) - Digital business card buyers cite convenience of contact sharing and reduced reliance on physical cards. - Messaging API buyers have described the vendor as an infrastructure partner for native messaging experiences in iMessage and related channels (vendor-published case descriptions). - Why some customers left for competitors (churn reasons) - For the digital business card product, common themes include subscription cost versus perceived value and usability trade-offs compared with alternatives. - For messaging use cases, buyers may prefer providers with more transparent pricing or different operational characteristics.

Vendor-published stories/testimonials

The vendor publishes customer stories and testimonials that describe high-volume messaging and large-scale deployments. These are vendor-originated and should be corroborated with independent customer references and verifiable operational metrics (timeframe, traffic profile, and scope).

Press coverage as supporting evidence

Industry coverage describes the product positioning and market events and supports the vendor's market narrative; press coverage is not equivalent to independently audited operational performance.

Methodology gaps to flag

All claims related to ROI, specific quantified cost savings, exact customer counts, and operational uptime or latency should be validated via signed SLAs, SOC 2 report scope, and references from customers running comparable workloads.

04Best fit

Company sizes

Likely fits (inferred): SMB to mid-market product teams and developer-led organizations (small to mid-sized companies) integrating an API for AI assistants, lead conversion, customer support automation, or transactional conversational workflows.
Enterprises can fit if they have the resources to operationalize compliance and an iMessage/RCS strategy; no definitive segmentation was published.

Industries and verticals where adoption is likely

Companies building conversational agents, AI-driven customer interactions, or customer engagement scenarios that prioritize native messaging experiences.

Roles and personas: decision makers and end users

Decision makers: Head of Product, VP Engineering, CTO, Growth/CRM leaders evaluating native messaging channels.
End users: Developers integrating APIs/webhooks; operations teams managing lines, compliance workflows, and monitoring.

Pain points and challenges the product addresses

Reduces friction for engaging customers inside native messaging apps (iMessage/RCS) and enables richer message types than SMS alone.

Qualification criteria: what makes a good fit

Requirement for native iMessage capabilities (reactions, voice notes, richer message formats) rather than SMS-only functionality.
Willingness to design conversational, one-to-one workflows rather than high-volume cold outbound blasts.
Ability to operate within documented rate limits and compliance constraints.

05The pitch

What the product does (core value proposition in objective terms)

- Linq describes itself as a communications API platform that enables businesses to send and receive messages over iMessage, RCS, SMS, and voice through a single API with automatic protocol fallback (e.g., iMessage → RCS → SMS). - Developer documentation describes a REST "Partner API" (current and legacy versions) with resources for chats, messages, phone numbers ("lines"), and webhooks to build conversational workflows and integrations. - Linq also has a separate product presence in the market as a digital business card product (hardware + app + profiles). The brand name "Linq" can refer to either the messaging API business or the digital business card product depending on context; this creates potential ambiguity when reviewing online information.

Target market and market positioning

Primary (based on vendor positioning): developer-focused teams and companies building AI agents or platforms that require native messaging experiences inside iMessage/RCS (rich media, reactions, voice notes, group chats) and an alternative to per-message SMS pricing models.
Secondary/legacy (based on review platform listings): individual professionals and teams using NFC/QR digital business cards for lead capture and networking workflows.

Get a comprehensive analysis of Linq including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →