Agents on Linq can already collect money. Starting today, they can spend it too.

We've partnered with [Agentcard](https://www.agentcard.sh/), the Y Combinator-backed company building card issuing for agent-first startups, to give every agent on Linq the ability to pay on a user's behalf. Ask your agent to book the flight, order the sushi, or renew the subscription, and it can now finish the job right in the thread, with a single-use virtual card scoped to that exact purchase. Card credentials never touch Linq's infrastructure or yours.

"The best checkout experience we could imagine was actually no checkout experience. The agent should be able to safely and seamlessly checkout on your behalf. That’s what we’re enabling with Agentcard." said Elliott Potter, CEO and co-founder of Linq.

"We built Agentcard so agents could spend safely: one card per purchase, scoped to the merchant and the amount, expired the moment it clears," said Karen Serfaty, CEO and co-founder of Agentcard. "Linq agents already live where users actually are, in their messages. Putting purchasing power in those threads is the most natural home for agentic commerce we've seen."

Here's how activation works, what a payment looks like end to end, and where card data actually lives.

## How activation works

You enable Agentcard from your Linq dashboard. A hosted onboarding flow connects the provider to your organization:

```
POST /v3/payments/providers/agentcard/connect
```

Starts hosted onboarding and links Agentcard to your org.

From there, your agent connects each customer by their handle, the phone number or email you already message them at:

```
POST /v3/payments/handles/{handle}/connect
```

Initiates a card connection for one customer.

The customer completes a one-time verification directly in the messaging thread. When they finish, a `connection.created` webhook confirms the handle is ready to pay. No app download, no new account, no card form.

## What a payment looks like

To pay, the agent creates a payment with the handle, amount, currency, and merchant details, with an `Idempotency-Key` header so retries are safe. The response `status` tells you where things stand:

```json
{ "status": "awaiting_user_action", "url": "https://..." }
```

The user has a step to complete; the agent sends them the URL in the thread.

A payment moves through three states. `needs_connection` means the customer has not linked a card yet. `awaiting_user_action` means a verification or approval step is pending, and the response includes a shareable URL. `ready` means the agent can retrieve credentials and check out:

```
GET /v3/payments/{paymentId}/credentials
```

Returns a short-lived token and fetch URL for retrieving card details directly from the provider.

Credentials are display-and-use only. Linq never stores them, and the single-use card they unlock is scoped to that purchase.

## When things go wrong

Failure cases are explicit rather than silent. A payment against an unlinked handle returns `needs_connection` instead of failing downstream. Declined authorizations arrive as webhooks, as do successful ones, so both sides have a record. Connections can be revoked at any time, which fires a `connection.revoked` webhook. Payments can be canceled, credential handoffs expire quickly, and Agentcard monitors spend patterns and blocks unusual activity on its side.

## Get started

Agentcard on Linq is available today. Linq customers get Agentcard's Light plan for free, with up to 200 cardholders and unlimited cards included. Enable it via the toggle on your Linq admin dashboard, then see the [Agentcard docs](https://docs.linqapp.com/guides/agentcard/) for the full API reference. Your agent already knows what your users want. Now it can buy it.

Three principles guided the integration:

- **Single-use by default.** Every purchase runs on a virtual card that works once, for that transaction, and then expires.  
- **The user stays in the loop.** Connections require one-time verification in the thread, and every payment is scoped to a specific merchant and amount.  
- **Credentials stay out of your stack.** Card details come from the provider through a short-lived handoff and are never stored by Linq or by you.

Agents built on Linq can now pay on their users' behalf with single-use virtual cards from Agentcard.

Your agent can buy things now: introducing Agentcard on Linq

Traditional texting APIs were built for one-way notifications—like verification codes, appointment reminders, delivery updates, and marketing messages.

However, AI agents need APIs that facilitate dynamic, two-way conversations with users. That means being able to receive messages, respond quickly, maintain context, and exchange rich media without relying on a human operator. The underlying infrastructure should also provide reliable routing, enterprise-grade security, and support for continuous back-and-forth messaging.

This buyer's guide breaks down the three main types of texting APIs available today, how each category works, and what to consider when choosing a texting API for your AI agent.

## What is a texting API?

A texting API is a software interface that lets an application send and receive text messages automatically. Instead of relying on a person to use a phone, the application connects to a messaging provider via code. It can then send messages, receive replies, track delivery status, and handle media or attachments where supported.

Depending on the provider, a texting API may support SMS, MMS, iMessage, RCS, or several channels at once. This allows autonomous systems to send instant alerts, answer customer queries, and manage two-way conversations at scale without human intervention.

## Why a business would need a commercial texting API

When a business needs to communicate with users at scale, a commercial texting API makes it possible. Without it, they would struggle to manually reply to dozens, hundreds, maybe even thousands of conversations.

A business may need a commercial texting API to:

- **Automate two-way conversations.** A texting API lets an AI agent or application send messages, understand replies, and continue the conversation without human input.
- **Reach users on familiar channels.** Businesses can communicate through SMS, MMS, iMessage, RCS, or other supported channels without requiring users to download a separate app.
- **Handle higher message volumes.** Programmable infrastructure can process far more conversations than a team using physical phones or manual messaging tools.
- **Track message delivery.** Delivery receipts and error updates help your application confirm whether a message arrived and respond when something goes wrong.
- **Support richer interactions.** Depending on the channel, your application can send images, videos, links, documents, and other rich media alongside text.
- **Connect conversations to business systems.** Messages can trigger actions such as scheduling an appointment, updating an account, checking an order, or creating a support request.
- **Improve reliability and oversight.** Commercial texting APIs provide delivery monitoring, security controls, compliance support, and infrastructure maintenance that would otherwise need to be handled in-house.

## The three types of texting APIs in 2026

Texting APIs generally fall into three categories, based on how they handle messaging and conversations. Understanding what they are can help you choose the right category and then the right API within it.

### Legacy SMS/CPaaS APIs

Legacy Communications Platform as a Service (CPaaS) providers are infrastructure-heavy solutions built by traditional telecommunication vendors.

These platforms were engineered for high-volume, one-way broadcasting rather than fluid, two-way conversations. This makes them a great choice for simple notification use cases, like one-time passwords, account alerts, appointment reminders, delivery updates, and marketing campaigns.

**Key characteristics include:**

- **Broad carrier access.** They let applications and AI agents send SMS and MMS to users across different mobile networks and countries.
- **Carrier-based pricing.** Costs may include per-message fees, message segment charges, phone number fees, and carrier surcharges, which make pricing harder to predict.
- **Registration requirements.** Businesses sending application-to-person (A2P) messages to US numbers may need to complete A2P 10DLC registration (which can take weeks) and comply with carrier rules.
- **No native iMessage support.** These platforms can send SMS and MMS, but they don't support native iMessage features such as blue bubbles, read receipts, and richer media.
- **Limited agent infrastructure.** The API handles message delivery, but your team still needs to build logic to track conversation history, verify user identities, route messages, and trigger agent workflows.

### iMessage point solutions

iMessage point solutions are specialist providers that layer iMessage capabilities on top of infrastructure originally built for outbound business texting.

They help sales and marketing teams bypass spam filters and low open rates associated with traditional SMS by delivering branded, blue-bubble messages directly to Apple users.

**Key characteristics include:**

- **Support for richer interactions.** Depending on the provider, these platforms may support rich media, including images, videos, and documents, as well as interactive features like read receipts, typing indicators, and reactions.
- **A strong focus on outreach workflows.** Many iMessage point solutions were built around outbound use cases such as sales follow-ups, lead nurturing, CRM outreach, and notifications.
- **Two-way messaging through webhooks.** Applications can receive replies and continue conversations, but your team may still need to build logic to maintain context, coordinate agent actions, and manage complex conversation flows.
- **Limited support for agent-led conversations.** These platforms make it easier to reach iPhone users via iMessage, but they lack the infrastructure to sustain back-and-forth conversations between AI agents and users.

### Agent-native messaging infrastructure

Agent-native messaging infrastructure is the most sophisticated texting API. It's built for applications and AI agents that need to hold continuous, two-way conversations with users.

Reciprocity (the ability to send and receive messages) is a part of the architecture from the start, rather than a feature tacked onto a system designed for one-way notifications or outbound outreach.

A great example of this type of texting API is [Linq](https://linqapp.com/).

**Key characteristics include:**

- **Two-way messaging by design.** The infrastructure supports sustained back-and-forth exchanges, allowing agents to receive messages, respond quickly, and follow conversation context over time.
- **Built around agent workflows.** When a user sends a message, the API delivers it to your server through [a webhook](https://docs.linqapp.com/guides/webhooks/). The server then passes the message to an LLM, such as GPT or Claude, and sends the agent's response back via the messaging API.
- **Native support for richer messaging.** The infrastructure supports channels like iMessage, RCS, and SMS, as well as rich media, [typing indicators](https://docs.linqapp.com/guides/chats/typing-indicators/), [group chats](https://docs.linqapp.com/guides/chats/group-chats/), read receipts, [Tapback reactions](https://docs.linqapp.com/guides/messaging/reactions/), and message threading.
- **Low-latency delivery.** Agent-native texting APIs like Linq process messages extremely quickly, helping agents respond at the pace of a natural conversation.
- **Built-in reliability and routing.** The platform selects healthy sending numbers, routes around delivery issues, reuses existing conversations, and handles failover without requiring your team to build that logic from scratch.
- **Secure messaging infrastructure.** Encryption, access controls, and compliance safeguards help protect sensitive user information and reduce security risks.
- **No per-message pricing.** Agent-native texting APIs often use flat or usage-based pricing rather than per-message pricing. This makes costs easier to predict as conversation volume increases.

## The 10 best texting API options for your business

We compared ten of the top texting APIs against the features that matter most for AI agents. Here's how they stack up:

| | Two-way support | iMessage | SOC 2 Type II Certified | Contractual uptime SLA | Flat pricing | Test sandbox (setup time) |
| --- | --- | --- | --- | --- | --- | --- |
| 1. Linq | Yes | Yes | Yes (and the only SOC 2 Type II–certified for iMessage API) | Yes (99.95%) | Yes (fee per active number) | Yes (~5 min) |
| 2. Twilio | Yes (SMS/RCS) | No | Yes | Yes (99.95%) | No | Yes (free trial) |
| 3. Vonage | Yes | No | Yes (Network APIs) | Yes (99.99%) | No | Yes |
| 4. Bird (MessageBird) | Yes (SMS, omnichannel) | No | Yes | Yes (99.95%) | No | Yes |
| 5. Plivo | Yes | No | Yes | Yes (99.99%) | No | Yes (free trial) |
| 6. Telnyx | Yes | No | Yes | No | No | Yes (free trial) |
| 7. Infobip | Yes | No | Yes | Enterprise contracts only | No (custom/negotiated) | Yes (60-day trial) |
| 8. Sinch | Yes | No | Yes | Yes (99.95%) | No | Yes (free trial) |
| 9. Bandwidth | Yes | No | Not publicly stated | Yes (99.999%) | No | Not stated |
| 10. SignalWire | Yes | No | Yes | Yes (99.95%, 99.99% dedicated) | No | Yes |

Here's a deeper look at the tools that qualify as the best texting APIs on the market in 2026:

### Linq

Linq is built specifically as agent-native infrastructure. Reciprocity (sending and receiving messages) is part of the architecture from the start. It combines native iMessage support with RCS, SMS, and Voice, backed by a 99.95% uptime SLA, under-120ms latency, and flat per-number pricing instead of metered per-message costs. For teams building AI agents that need to hold real, ongoing conversation, rather than just send outbound blasts, it's the only option in this list built around that use case from the ground up.

### Twilio, Vonage, Bird, Plivo, Telnyx, Infobip, Sinch, SignalWire (Enterprise CPaaS)

These legacy texting API tools are built for OTPs, alerts, and marketing at global scale, with broad carrier reach and mature developer tooling. Most of them carry SOC 2 Type II certification, and several publish strong uptime SLAs. Vonage and Plivo sit at 99.99%, with the others around 99.95%. None of them support native iMessage, though, and pricing across the board is metered per message or negotiated at enterprise scale rather than flat, which makes costs harder to predict as an AI agent's conversation volume grows.

They're also generally architected for one-way or broadcast-style messaging rather than the sustained, context-aware two-way exchanges agent use cases need.

### Bandwidth

Bandwidth runs its own Tier-1 carrier network rather than reselling access, which gives it a strong 99.999% uptime claim and direct-to-carrier reliability. It's metered per message, not flat, and unlike most others on this list, it doesn't publicly state SOC 2 Type II certification, which is worth confirming directly if compliance is a procurement requirement.

There's no native iMessage support with Bandwidth.

## How to choose the right texting API for your AI agent use case

Choosing a texting API involves more than comparing messaging channels and usage fees. You also need to consider how well the platform supports two-way conversations, handles delivery issues, protects user data, and fits your development timeline.

Here's a checklist to use when comparing texting API providers:

- **Reciprocity.** Make sure the API supports two-way messaging, so your agent can both send messages and receive replies. It should also support rich media (images, videos, documents, and audio files), group chats, typing indicators, and read receipts without requiring your team to build those features separately.
- **Reliability.** Check how the provider handles failed messages, routing problems, and service interruptions. Features like automatic failover and delivery tracking reduce the work your team has to handle.
- **Compliance and security.** Review the provider's security standards (SOC 2 Type II, HIPAA, GDPR, etc.), encryption, access controls, data policies, and compliance certifications. Also, check whether you need to manage carrier registration or other messaging requirements yourself, or whether the platform handles them as well.
- **Pricing model.** Look beyond the subscription price and account for per-message fees, carrier surcharges, phone number charges, registration costs, and usage limits. Choose a pricing model that keeps costs easy to predict as your agent supports more users and longer conversations.
- **Speed to launch.** Your team should be able to launch two-way messaging within a week or less. So, look for platforms that have clear documentation, straightforward webhooks, useful SDKs, a reliable test environment, and managed routing to help you get things up and running quickly.

## Why choose Linq as your go-to texting API?

Linq is built for teams that want to launch reliable, two-way messaging without spending months assembling the infrastructure themselves. Here's what sets it apart from other texting APIs:

- **99.95% uptime with a contractual SLA.** Linq guarantees 99.95% uptime in your contract as a service-level agreement (SLA). So if you need your agent to text customers around the clock, you can count on Linq to be available.
- **Under 120ms latency.** Linq sends messages in under 120 milliseconds. At that speed, your agent's replies arrive fast enough for the conversation to feel natural, as if a person were on the other end of the line.
- **SOC 2 Type II certified.** Linq has SOC 2 Type II compliance (and is the only API provider with SOC 2 Type II compliance for iMessage), which provides your security, legal, and procurement teams with independent evidence that Linq protects user data, controls access, and follows audited procedures for handling security incidents. This helps you pass vendor reviews before launch.
- **A working testing sandbox.** Linq provides a sandbox where you can set up and test your messaging workflow in about five minutes. This allows you to confirm that everything works as expected before upgrading to a paid plan.
- **No per-message pricing.** Linq charges a flat subscription fee per active phone number rather than per message. This way, your agent can send and receive thousands of messages without inflating your monthly costs.

Companies like The Interaction Company of California use Linq to build products that meet people where they already are. Their AI assistant, Poke, started as a simple email summarizer until the team realized users wanted AI they could actually talk to, right in iMessage.

Instead of a traditional waitlist, they launched with a chatbot "bouncer" that let users negotiate their own membership price, sparking an engaged community from day one. It's a glimpse of what's possible when a texting API is built to scale with you.

> "Linq feels like a cloud provider, it just scales with us. I think there are a lot of other providers on all parts of our infrastructure that would not be able to keep up."
> — Interaction Co. California

**👉 Read:** [Why Lindy chose us as their iMessage API](https://linqapp.com/blog/best-imessage-api)

## Connect your AI agents to users with Linq

![Connect your AI agents to users with Linq](https://res.cloudinary.com/linq/image/upload/v1785165718/Texting_API_Buyer_s_Guide_kjkryu.png)

Texting APIs give businesses a programmable way to communicate with users, whether that means sending one-way alerts and verification codes or supporting ongoing, two-way conversations.

Linq is an agent-native texting API that lets you connect your AI agent to users through iMessage, RCS, and SMS. It supports incoming and outgoing messages, rich media, group chats, read receipts, typing indicators, and reactions such as Tapbacks, giving your agent the tools to communicate more naturally.

Ready to test it? [Use Linq's free sandbox to set up a messaging workflow](https://dashboard.linqapp.com/sandbox-signup/) in five minutes or less.

## FAQs

### What's the difference between a texting API and an iMessage API?

A texting API is a software interface that lets applications and AI agents send messages, whether that's SMS, MMS, RCS, or iMessage.

An iMessage API, on the other hand, is a specific type of texting API designed to connect AI agents to Apple's native iMessage platform. These APIs include iMessage-specific features like read receipts, typing indicators, group chats, and rich media.

### Is there a free texting API?

Many texting APIs give you a free sandbox where you can send test messages, set up webhooks, and confirm that your workflow works the way you expect. However, to connect a dedicated business line and let your agent communicate back and forth with users, you need a paid plan.

### Do I need A2P 10DLC registration for a commercial texting API?

Yes. If you plan to send messages from a standard 10-digit phone number to US mobile numbers, A2P 10DLC registration is mandatory.

Major mobile carriers require this registration to prevent spam and verify your business identity. Failure to register results in message blocking, heavy carrier filtering, or severely restricted daily message limits.

Registration includes two primary steps:

- **Brand registration.** You register your company's legal details (such as an EIN/Tax ID) with a central database called The Campaign Registry. This assigns you a Trust Score.
- **Campaign registration.** You declare your messaging use case (e.g., marketing, appointment reminders) and define your message flows.

Approval usually takes 1–4 weeks. The exact fees and throughput limits (how many texts you can send per second) depend on your API provider (e.g., Twilio or Plivo).

But if you want to connect your agent to iMessage specifically, you can skip registration. An iMessage API like Linq runs on Apple's network instead of the carriers', so it sidesteps 10DLC entirely, which helps you launch faster.

### Can a texting API support two-way AI agent conversations?

Yes, if it's built for two-way messaging. The API receives each inbound message via a webhook, passes it to your LLM, and sends the response back to the same thread.

Older SMS APIs can do this, but because they were originally built for one-way blasts, their conversational infrastructure is not as robust as that of tools like Linq, which were built with reciprocity in mind.

### How much does a commercial SMS texting API cost?

Legacy vendors typically charge a small fee per message (around $0.0085), but add variable carrier surcharges that make high-volume costs unpredictable. Other platforms, like Linq, offer a flat fee per dedicated line, allowing your agent to communicate with thousands of customers without inflating your monthly bill.

A buyer's guide to texting APIs for AI agents. Compare iMessage, RCS, and SMS providers on uptime, SOC 2 compliance, latency, and pricing before you build.

The Best Texting API for AI Agents in 2026: A Buyer's Guide

Today we're launching support for [Natural](https://www.natural.com/) in Agent Pay. Businesses on Linq can now create a Natural wallet directly from the admin panel, and request and receive payments from their users over iMessage, settling into that wallet. It works alongside the Stripe rail Agent Pay launched with, through the same API, with one new parameter.

## Why we built it

Agent Pay has always settled directly to your own Stripe account. That model is right for a lot of businesses, and it isn't going anywhere. But it asks something of you: a Stripe account, Stripe's verification, and the responsibilities of being the merchant of record.

A growing share of what's built on Linq doesn't fit that shape. Teams are shipping agents that hold funds, businesses want to collect over text without operating a payments stack, and money is starting to move between parties that are software. Natural was built for exactly this: custodial wallets with verified identities, audit trails on every transaction, and an API designed for automated money movement. Pairing it with iMessage means the request for payment shows up in the same thread where the conversation already happened, from a number the payer already knows.

## How it works

Onboarding starts in the Linq admin panel. Your payments settings now include Natural onboarding; completing it verifies your business and creates your wallet. Requests you create through Linq show up there, and your balance, payouts, and the rest of your wallet activity live in your Natural account, with the Natural dashboard giving you wallet-level visibility.

Once you're onboarded, collecting a payment is one API call. Set `rail` to `natural`, address the payer by phone number, and send from a line your organization owns:

```shell
curl -X POST https://api.linqapp.com/v3/payment_requests \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -d '{
    "rail": "natural",
    "amount": 4000,
    "currency": "usd",
    "from": "+14045550132",
    "payer_handle": "+14155550178",
    "description": "Training session, July 24"
  }'
```

The request lands in your user's Messages thread. They pay, the funds settle to your wallet, and you get the same `payment.succeeded` webhook you already handle, so your reconciliation code works unchanged.

## Built on verified identity

A payment request in a text thread is only as good as the payer's confidence in who sent it. Every organization collecting on the Natural rail completes Natural's business verification before it can charge, every wallet is tied to a verified legal entity, and every request is sent from a line your organization owns. Every transaction carries a full audit trail on both sides.

## Get started

Natural onboarding is available today for every organization, in the payments settings of the admin panel. Complete verification, send your first request with `rail: "natural"`, and you're collecting over iMessage. The [payment rails documentation](https://docs.linqapp.com/guides/payments/#payment-rails) covers both rails in depth.

We believe the thread is where more and more business will get done, and payments belong where the conversation is. This launch closes the gap between the two.

Linq now supports Natural: spin up a wallet in minutes in the Linq Admin and get paid right inside iMessage, in the same thread where the conversation is already happening.

Linq Agent Pay now supports Natural

If you want to connect an AI agent or custom software to native iMessage, you have two options: build the integration from scratch or save yourself the time and burden with an [iMessage API](https://linqapp.com/imessage-api).

Linq's API gives you native, two-way iMessage support without requiring your team to run the hardware and account infrastructure behind it. You also get rich media support, group chats, fast delivery, flat-rate pricing, and enterprise security built in.

In this article, we'll explain why Linq is the best iMessage API and why companies like Lindy chose us after trying to build the infrastructure themselves.

## Key takeaways

- Linq provides the infrastructure developers need to build and deploy AI agents and custom applications in iMessage without managing Macs, iPhones, Apple accounts, or message-routing hardware.
- It is the only enterprise-grade iMessage API with SOC 2 Type II compliance, helping businesses protect sensitive customer information and conversations, and giving them the documentation they need to pass security, legal, and procurement reviews.
- Linq supports two-way messaging, rich media (images, videos, audio, and attachments), [group chats](https://docs.linqapp.com/guides/chats/group-chats/), Tapbacks, [typing indicators](https://docs.linqapp.com/guides/chats/typing-indicators/), and threaded replies.
- Messages are delivered with P95 latency below 120 milliseconds and backed by a contractual 99.95% uptime SLA.
- Our flat-rate line pricing keeps costs predictable, while the free sandbox lets developers test the full messaging flow before upgrading to a paid plan.

## What makes an iMessage API "the best"?

Beyond sending blue-bubble messages, the best iMessage API should support the speed, context, and message volume required by AI agents, customer support platforms, CRMs, sales tools, and other products built around ongoing conversations.

Some criteria the API should meet include:

- **Ultra-low latency:** Messages need to be sent and received quickly enough for the conversation to feel natural, even when the agent is generating a response in real time.
- **Rich media support:** In addition to text, the API should also be able to process and send high-resolution images, video, and audio files (voice notes).
- **Interactive features:** The API should support iMessage-specific UI elements such as Tapbacks (reactions), inline replies, typing indicators, and thread management, so the agent doesn't lose context in active conversations.
- **Reliable delivery and routing:** The provider should handle queues, retries, delivery events, number capacity, traffic balancing, and failover without your team having to manage each device or account. It should also offer clear uptime guarantees, detailed delivery logs, and useful error messages so your team can quickly diagnose failed or delayed messages.
- **Compliance and security:** The API should protect message data with encryption, signed webhooks, strict access controls, and independently verified security standards. It should also provide enterprise teams with clear policies around data handling, retention, and internal access.
- **Fast setup:** Developers should be able to easily get API keys, test in a sandbox, configure webhooks, and send a first message without provisioning Mac Minis, iPhones, or Apple accounts.
- **Sensible pricing:** AI agents often generate long, back-and-forth conversations, so the API should offer flat-rate or volume-based pricing to keep costs predictable, rather than per-message carrier fees that increase with usage.

## What makes Linq the best iMessage API?

What sets Linq apart from standard iMessage gateways is that our entire technical architecture was intentionally built for the AI era and for products that depend on fast, two-way communication.

Traditional SMS APIs, like Twilio, were built for one-way mass-notification blasts & sending verification codes, but Linq supports ongoing, two-way exchanges between users and the products, teams, or AI agents that serve them.

Here's what makes Linq the best iMessage API:

### Reliability at scale

Building an iMessage integration yourself means taking responsibility for far more than the API layer. You also need physical Macs, paired iPhones, Apple accounts, custom bridge software, monitoring, message routing, and a plan for when any part of that setup fails.

[Lindy wrote about their experience building iMessage integration themselves](https://www.linkedin.com/pulse/how-we-built-imessage-lindy-lindyai-jpnsc/). Its original iMessage infrastructure ran on a Mac Mini in a Las Vegas data center, paired with an iPhone and powered by a custom Swift daemon that monitored the Messages database and sent messages through Apple's private frameworks. The bridge worked, but only one engineer knew Swift well enough to maintain it.

The team then rebuilt the system with BlueBubbles so more engineers could debug it in JavaScript. That made the code easier to support, but it did nothing to remove the hardware burden. Every phone number still needed its own Mac Mini, iPhone, and Apple account.

On launch day, usage surged, and Apple permanently banned the account.

![What makes Linq the best iMessage API? ](https://res.cloudinary.com/linq/image/upload/v1784736272/Linq_-_Image_1_1_jjflf3.png)

Buying another device stack would only restart the same cycle, so for their third rebuild in four weeks, Lindy's team turned to an iMessage API: Linq.

Instead of provisioning more hardware and hoping the next account lasted longer, Lindy replaced the bridge with a REST API. The initial rebuild took four hours, and the full migration took a few days. Soon after, the team was able to delete 76 files and thousands of lines of bridge code because Linq now handled the hardware, accounts, routing, and anti-spam controls for them.

### Complete compliance as the only SOC 2 Type II iMessage API

Apple doesn't provide a public business API for iMessage, so automated messaging can trigger its internal spam controls and lead to sudden account suspensions. Lindy experienced this firsthand when a surge in launch-day traffic led to a permanent ban.

That risk makes strong security and operational controls essential for any production deployment.

Linq is the only enterprise-grade iMessage API provider with SOC 2 Type II compliance. This provides procurement, legal, and security teams with independent evidence that Linq adheres to established controls for protecting data, managing access, maintaining system availability, and responding to security incidents.


These protections are especially important when customers share phone numbers, email addresses, attachments, account details, or other sensitive information with you via iMessage. Linq also provides the documentation your team needs to pass vendor security reviews, meet customer requirements, and get approval from internal stakeholders before launch.

### Reciprocity that feels human with ultra-low latency

Unlike a notification tool that only sends information out, an AI agent also needs to understand replies, respond in context, and keep the conversation flowing.

Linq is built for that kind of two-way communication. When a user sends a text, an attachment, an inline reply, or a Tapback reaction, Linq routes the event to your server through event-based webhooks. Your application can then pass the message and its context to the AI model you use, such as GPT or Claude, generate a response, and send it back into the same conversation.

The exchange happens quickly. Once your agent finishes generating its reply, Linq delivers the message with P95 latency below 120 milliseconds, allowing replies to reach the user almost immediately after they're generated.

This back-and-forth extends beyond text. With Linq, your agent can send and receive images, videos, documents, audio files, and [voice memos](https://docs.linqapp.com/guides/messaging/voice-memos/). It can also use typing indicators, read receipts, reactions, and threaded replies to make each conversation feel natural and easy to follow.

### You are up and live in minutes, not months

Building an iMessage integration yourself can take weeks because you have to provision hardware, pair devices, manage Apple accounts, write the bridge, and test every part of the message flow.

With Linq, you can send and receive your first iMessage in less than five minutes using a test number, like your own iPhone. Once the basic loop works, an experienced developer can connect the line to OpenAI, Anthropic, LangChain, or another AI stack in about 20 to 30 minutes.

Linq also eliminates the registration delays associated with traditional business texting. A2P 10DLC approval often takes three to four weeks, but Linq can provision a production-ready enterprise number as soon as your commercial agreement is finalized.

For teams migrating an existing build, the process takes longer but still moves quickly. Lindy completed its full migration to Linq in a few days, and most similar migrations can be finished in less than a week.

**Read:** [Getting started with Linq's sandbox](https://docs.linqapp.com/getting-started/quickstart/)

### Fair and predictable iMessage API pricing

Per-message pricing can add up quickly, especially when an AI agent or customer-facing product is handling thousands of customer conversations at once. A single support thread or brainstorming session can easily reach 50–100 messages, and traditional pay-per-message APIs charge for each one.

Linq takes a different approach. We charge a flat subscription fee per active phone number, which keeps your monthly costs predictable as usage grows. Your agent/product can hold long conversations, send multi-paragraph replies, exchange rich media, and process millions of texts without every additional message increasing your bill.

Developers can also test the full experience before paying. Linq offers a free sandbox where your team can build and test two-way messaging loops, webhooks, and responses before moving to a business number.

## Is Linq the best iMessage API for you?

Linq is designed for teams that want to integrate an AI agent, support platform, or other custom software with native iMessage without operating the device, account, and delivery infrastructure themselves.

You're likely a fit if:

- **You need a product or team that can hold ongoing conversations with users.** Linq works for AI agents, customer support teams, sales platforms, scheduling tools, and other products that rely on fast, two-way messaging. It supports rich media, [Tapback reactions](https://docs.linqapp.com/guides/messaging/reactions/), typing indicators, read receipts, and threaded replies.
- **You want to launch without running your own iMessage hardware stack.** Linq manages the Macs, phones, Apple accounts, monitoring, and message delivery behind the API.
- **You need enterprise security and reliability.** Linq offers SOC 2 Type II compliance, encrypted message data, ultra-low latency, and a contractual 99.95% uptime SLA.
- **You expect usage to grow.** Our flat-rate pricing per active number makes it easier to forecast costs as conversations get longer and message volume increases.
- **You already have an iMessage integration, but no longer want to maintain the infrastructure behind it.** You can keep your agent logic and product workflows while Linq handles routing, delivery, account management, and anti-spam operations.

## Build a Better iMessage Experience With Linq

You can build an iMessage integration yourself, but doing so means taking responsibility for the hardware, Apple accounts, routing, delivery, compliance, and ongoing maintenance behind every message. Running all of that in-house is expensive and gives your team more infrastructure to monitor, troubleshoot, and maintain.

![What can you build with Linq's iMessage API](https://res.cloudinary.com/linq/image/upload/v1784736334/Linq_-_Image_2_1_csum9t.png)

With Linq, however, you get a managed API that handles two-way messaging, with rich media support, low-latency delivery, predictable pricing, and SOC 2 Type II compliance. This leaves your engineers free to focus on improving the product, refining its workflows, and creating a better user experience.

Ready to see how it works? [Set up your iMessage integration in Linq's sandbox for free](https://dashboard.linqapp.com/sandbox-signup/).

## FAQs

### Is there a free iMessage API?

Yes. Linq offers a free sandbox where developers can test two-way iMessage workflows before upgrading to a paid plan. You can send and receive messages, configure webhooks, and connect your application or AI model using a temporary test number. This allows you to validate the full message flow before paying for a live, provisioned phone line.

### What's the difference between an iMessage API and SMS API?

An iMessage API works within Apple's closed messaging ecosystem, allowing AI agents and custom applications to send native blue-bubble messages to users. It also supports rich media, including images, videos, audio files, and voice notes, as well as iMessage-specific features like Tapbacks, typing indicators, group chats, inline replies, and interactive apps.

An SMS API, on the other hand, sends green-bubble messages over mobile carrier networks. It works across a wider range of devices, but it's generally limited to basic text and static media and does not support the same real-time interactive features.

### Can Linq replace a self-built iMessage integration?

Yes. Linq can replace the hardware and account infrastructure behind a self-built iMessage integration without requiring you to rebuild your AI agent or product workflows. Instead of maintaining Macs, phones, Apple accounts, routing, monitoring, and account health yourself, your team connects to Linq through a REST API and webhooks. And Linq handles the rest for you.

### Does Linq support group chats and rich media?

Yes. Linq supports group chats and rich media, including images, videos, documents, audio files, and voice notes. Your application can receive these through webhooks, pass them to an AI model or another backend system for processing, and send media back into the same thread.

Linq also supports Tapbacks, inline replies, typing indicators, and read receipts, so the agent can keep track of context and respond appropriately in active chats.

### How fast can I get an iMessage API live?

Deployment time depends on the API, your existing stack, and whether you're starting from scratch or migrating an existing build.

With Linq's sandbox, you can start sending and receiving test iMessages in less than five minutes. An experienced developer can usually connect the messaging flow to an LLM, support platform, or backend workflow in 20–30 minutes, while production provisioning and larger migrations can take a few days (but are generally concluded in less than a week).

Is Linq the best iMessage API? See why Lindy ditched their DIY build for Linq's two-way, low-latency infrastructure.

Are We the Best iMessage API? Here's Why Lindy Chose Linq

Messages don't always arrive. Carriers drop them, devices go offline, and an iMessage can quietly fall back to SMS. Each of these failures is rare on its own and constant in aggregate. At any real volume, some fraction of your sends fail for reasons outside your control.

A send call in isolation cannot tell you this. When you `POST` a message to the Linq API, the response comes back before the message has gone anywhere. A `200` means we accepted your request and queued it for processing. It does not mean the message reached a device, and it does not necessarily mean it ever will.

Message status webhooks give you visibility into what happened after that send. In this post we'll walk through the message lifecycle events Linq emits over webhooks, why `sent`, `delivered`, and `failed` each carry information you can't get any other way, and how to build an endpoint that holds up in production.

## The send response is an acknowledgement

A send is asynchronous. When we receive your request, we return quickly and queue the work: dispatch over iMessage, RCS, or SMS, negotiate the protocol, and retry transient upstream errors. The response confirms we have the request. The delivery outcome is decided later, over the following seconds to minutes.

We report that outcome as a small set of webhook event types. Each one sets a different timestamp on the message.

| Event | Meaning | Timestamp set |
| :---- | :---- | :---- |
| `message.sent` | We sent the message from your number. `delivered_at` and `read_at` are still `null`. | `sent_at` |
| `message.delivered` | The message reached the recipient's device. | `delivered_at` |
| `message.read` | The recipient opened it (requires read receipts enabled). | `read_at` |
| `message.failed` | Hard delivery failure, with an error `code` and `reason`. | `failed_at` |

Every event arrives in a common envelope: an `event_type`, a unique `event_id`, a `trace_id` for debugging, and an event-specific `data` block. Here is a `message.sent` payload.

```json
{
  "api_version": "v3",
  "webhook_version": "2026-02-03",
  "event_type": "message.sent",
  "event_id": "e20feb41-7f67-43f0-89c8-a985cff3b568",
  "trace_id": "2eff5df5c6f688733c007523c4d61cd9",
  "data": {
    "id": "347d62c2-2170-4754-8d30-c76d0c727d96",
    "direction": "outbound",
    "sent_at": "2026-02-05T19:52:17.219Z",
    "delivered_at": null,
    "read_at": null,
    "service": "iMessage"
  }
}
```

The state machine matters more than any single event. `sent` to `delivered` to `read` is the path a healthy message follows. A `sent` that turns into `failed`, or a `sent` that never advances to `delivered`, is where your logic should react.

## What each status tells you

`message.sent` confirms dispatch and gives you a latency baseline. It means we got the message out of the queue and onto the network. Its `sent_at` timestamp is the anchor for everything downstream. For time-sensitive traffic like one-time passcodes, fraud alerts, and appointment confirmations, the gap between your API call and `message.sent` is where a latency regression first shows up. Without this event, you are inferring dispatch from the absence of an error, which is a weaker signal.

`message.delivered` confirms the message reached a device. This is the event to build delivery-rate dashboards on, broken out per number, per campaign, and per protocol. It is also the correct trigger for anything that should not fire early: start a "check your phone" countdown, escalate to a fallback channel, or mark a reminder as delivered in your CRM only once `delivered_at` is set. Treating `sent` as if it were `delivered` is a common and expensive mistake, because it hides real delivery failures behind an optimistic UI.

`message.failed` tells you a send failed and why. The event carries a `code` that maps to our [error code](https://docs.linqapp.com/error) list, a human-readable `reason`, and a `failed_at`.

```json
{
  "event_type": "message.failed",
  "data": {
    "chat_id": "550e8400-e29b-41d4-a716-446655440000",
    "message_id": "550e8400-e29b-41d4-a716-446655440001",
    "code": 4001,
    "reason": "Delivery failed",
    "failed_at": "2025-11-23T17:35:00.000Z"
  }
}
```

The code is what makes the failure actionable. A transient timeout (`4001`) is worth an automatic retry or a protocol fallback. An invalid-recipient error is not, and retrying it wastes throughput and reputation. Route failures into a dead-letter queue, alert on failure-rate spikes, and feed the reasons back into list hygiene. A `failed` event you drop is a customer who never got their code and a support ticket you pay for later.

## Not every protocol emits every status

This is the detail that separates a robust integration from a brittle one. SMS and MMS have no delivery-receipt or read-receipt mechanism at the protocol level. An SMS send produces `message.sent` when we accept it for delivery and `message.failed` on a hard failure. It never produces `message.delivered` or `message.read`, because those receipts do not exist on the protocol. iMessage and RCS do emit `delivered`, and emit `read` when the recipient has read receipts enabled.

The failure mode here is subtle. If your logic waits for `delivered` before treating a message as successful, every SMS fallback in your system will look permanently stuck. Read the `service` field on the event, and enforce a delivery SLA only on the protocols that can report one. We publish the full [protocol capability matrix](https://docs.linqapp.com/guides/messaging/protocol-selection) so you can encode this up front rather than discover it in production.

## Consuming webhooks in production

You can poll [`GET` message details](https://docs.linqapp.com/guides/messaging/message-details) to check `is_delivered` and `is_read`, but polling at scale is wasteful, slow, and rate-limited. Webhooks push the state change the moment it happens. In return, your endpoint is now receiving traffic from a distributed system, and it has to be built for that. Our [delivery guarantees](https://docs.linqapp.com/guides/webhooks/) state the contract, and each clause has a consequence for your handler.

Delivery is at-least-once, so duplicates are possible. Every event carries an `event_id`. Use it as an idempotency key and deduplicate. Processing the same `delivered` twice should be a no-op.

The response timeout is 10 seconds, after which we retry. Return `200` immediately and do the real work asynchronously. If you run business logic inline and it takes 11 seconds, we treat the delivery as failed and retry, and now you are processing duplicates and timing out at once.

We retry up to 10 times over roughly 25 minutes with exponential backoff on `5xx`, `429`, and connection errors. A brief outage on your side will not drop events. We do not retry `4xx` responses other than `429`. If your handler rejects a valid event with a `400`, that event is gone.

Events can arrive out of order. Do not assume `delivered` reaches you after `sent` in wall-clock time. Order your state machine by the timestamps on the events themselves (`sent_at`, `delivered_at`, `read_at`), not by the order you received them.

Because these events can trigger money movement and customer-facing actions, verify signatures. We sign every request using the [Standard Webhooks](https://www.standardwebhooks.com/) scheme: an HMAC-SHA256 over `{webhook-id}.{webhook-timestamp}.{body}`, a `whsec_`\-prefixed secret, and a 5-minute replay window. The SDKs reduce it to one call.

```javascript
import LinqAPIV3 from '@linqapp/sdk';

const client = new LinqAPIV3(); // reads LINQ_WEBHOOK_SECRET from env

// In your webhook handler. Pass the RAW body, not parsed JSON:
const event = client.webhooks.unwrap(rawBody, { headers: req.headers });
// Throws on an invalid signature. `event` is a fully typed, discriminated union.
```

One more thing worth doing up front: pin your [webhook version](https://docs.linqapp.com/guides/webhooks/) with `?version=YYYY-MM-DD` on the subscription URL. Payload shapes change over time. The `2026-02-03` version added `message.edited` and a `health_status` block that older subscriptions do not receive. Pinning keeps a platform update from reshaping the JSON your parser depends on.

## What this unlocks

Once status events are flowing, a set of features becomes straightforward. You can show accurate "Sent, Delivered, Read" state in your own UI instead of guessing. You can compute delivery rates per phone number and catch a [flagged or unhealthy number](https://docs.linqapp.com/guides/phone-numbers/) before it degrades a campaign; we push `phone_number.status_updated` events for exactly that case. You can drive fallback logic, close the loop on two-factor flows, and attach a `trace_id` to every failure for end-to-end debugging.

A few principles to consume these events well:

- **Treat `sent` and `delivered` as different states.** One means we dispatched the message; the other means it arrived. Only the second is delivery.  
- **Be protocol-aware.** Expect `delivered` and `read` on iMessage and RCS, and expect their absence on SMS and MMS.  
- **Make the handler idempotent.** Deduplicate on `event_id` and order by event timestamps, because delivery is at-least-once and events can arrive out of order.  
- **Acknowledge fast, process later.** Return `200` inside the timeout and move the work off the request path.  
- **Act on `failed`.** Branch on the error `code`, retry what is transient, and drop what is not.

The send call tells you we received your request. The status webhooks tell you whether the message reached the person on the other end, which is the only outcome your users experience.

---

*Reference: [Linq Partner API: Webhooks](https://docs.linqapp.com/guides/webhooks/), [Webhook Events](https://docs.linqapp.com/guides/webhooks/events/), and [Message Details](https://docs.linqapp.com/guides/messaging/message-details/).*  


Message status webhooks tell you what actually happened to a message after the send call returns, which is the only way to measure real delivery, act on failures, and avoid mistaking "dispatched" for "delivered."

Message status webhooks: sent, delivered, failed

Not long ago, building an AI agent that could send and receive iMessages meant relying on unofficial workarounds and hoping they held up. But that era is over.

Linq provides enterprise-grade infrastructure that lets your AI agent send and receive iMessages directly, so it can hold two-way conversations with users using text, links, emojis, and other rich media that feel human. You can also get it running in a couple of days, not weeks.

So how does it actually work? This guide walks you through the whole thing: what an iMessage API for AI agents is, what you need before you start, and a step-by-step framework for setting it up with Linq.

## What is an iMessage API for agents?

An iMessage API for agents is a software interface that allows an AI agent to send and receive text messages via Apple's native iMessage network.

No official Apple iMessage API exists (Apple limits iMessage to personal Apple devices), so third-party companies (like us) build specialized infrastructure that lets businesses and autonomous AI agents tap into the network.

Here's how:

- Your AI sends a message from a server, but it lands on the user's iPhone as a native blue bubble.
- Users reply to the AI exactly how they'd text a friend, and the AI processes the message instantly.
- The API lets your AI agent send and receive photos, videos, audio messages, and interactive links.

## Why are brands using iMessage as their AI agent's communication channel?

Deploying your AI agent via iMessage gives you a competitive edge by shifting the entire AI experience from a clunky web browser to a conversational layer people already trust and use every day.

Here's why brands [like Lindy](https://www.lindy.ai/blog/imessage-api-three-rewrites-one-apple-ban-and-what-actually-works) have quickly adopted iMessage for their AI agents:

- **The blue bubble builds trust.** People trust the blue bubble because it signals a verified contact, not a stranger. Unlike SMS from unknown numbers, which users often dismiss as spam or a marketing blast, a blue bubble reads like a text from someone they know. That's why [iMessage sees open rates near 98%](https://www.sendblue.com/blog/imessage-marketing-automation), compared to about 20% for email.
- **There's zero friction to start.** Your users don't need to install an app, create new login credentials, or navigate a clunky web widget because the agent appears inside an app they already have open. So they can simply reply the moment a message from your agent arrives.
- **Instant deployment.** Launching a business SMS line takes weeks of regulatory compliance and campaign approval through A2P 10DLC. iMessage, however, routes directly through Apple's servers rather than carrier networks, so you skip that process entirely and start sending messages right away.
- **Native UX features mask AI latency.** Large language models (LLMs) often take a few seconds to write a reply. With a provider like Linq, your agent can trigger the native iMessage "..." typing bubble while it thinks, so the wait feels natural. The agent can also send read receipts and tapbacks, making it feel like it's actively in the conversation.

## What you need before you start

Getting your agent running on iMessage is quick, but you'll need to have a few things ready before the first message can be sent, including:

- **An API key.** Your API provider gives you a bearer token that authenticates every request you make. Keep it somewhere safe, since it's how the API confirms each request is coming from you.
- **A phone number for your agent.** You'll need a dedicated number tied to your account. This is the number your agent texts from and the one users reply to.
- **A webhook endpoint.** You'll also need a public HTTPS URL to which incoming messages are sent. This is how your agent knows when a user has texted it.
- **The LLM you're wiring in.** This is the model that generates your agent's replies. If your API provider is model-agnostic, you can build on Claude, GPT, or another model that fits your use case.

## How to set up iMessage for your AI agent using Linq

Setting up your agent on iMessage with Linq is more straightforward than you might expect. Here's [a step-by-step framework](https://docs.linqapp.com/getting-started/quickstart/) to get your agent up and running in iMessage:

### Step 1: Get API access

First, [sign up for Linq's sandbox](https://dashboard.linqapp.com/) to get access to the Linq Partner API. From there, you'll need a bearer token. This token determines which phone numbers you can send from, which data you can access (chats, messages, and attachments), and your rate limits and daily message quotas.

![Generating a new API token in the Linq Developer Dashboard](https://asset.cloudinary.com/linq/9702894de0feb6c4f9151742adcf3f87)

You can get a token in two ways:

- **Generate one yourself** from the [Linq Developer Dashboard](https://dashboard.linqapp.com/api-tooling). Click **API** in the sidebar, select **Overview**, then tap **Generate new token**.
- **Ask your Linq partner representative.** They'll review your AI agent's conversational use case and provision an active enterprise bearer token straight to your account.

Once you have your token, copy it and store it in a secure file.

Before you go live, you can develop and test with Linq's sandbox. It gives you a temporary test phone number along with your API keys, so you can try everything out safely before trying to reach real users.

Once your code works perfectly in the sandbox, you can upgrade to a permanent phone number or link your brand's custom number to send blue-bubble messages.

### Step 2: Send your first message

In the sandbox, create a chat and send a plain-text iMessage to a number you can check (like your own phone) so you can watch it arrive.

Use whichever stack you work in.

**cURL**

```bash
curl -X POST https://api.linqapp.com/api/partner/v3/chats \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "+12223334444",
    "to": ["+15556667777"],
    "message": {
      "parts": [
        { "type": "text", "value": "Hello from Linq!" }
      ]
    }
  }'
```

**TypeScript**

```typescript
import LinqAPIV3 from '@linqapp/sdk';

const client = new LinqAPIV3({
  apiKey: process.env.LINQ_API_KEY,
});

const chat = await client.chats.create({
  from: '+12223334444',
  to: ['+15556667777'],
  message: {
    parts: [
      { type: 'text', value: 'Hello from Linq!' }
    ],
  },
});

console.log('Chat created:', chat.id);
console.log('Message ID:', chat.last_message?.id);
```

**Python**

```python
import os
from linq import LinqAPIV3

client = LinqAPIV3(api_key=os.environ["LINQ_API_KEY"])

chat = client.chats.create(
    from_="+12223334444",
    to=["+15556667777"],
    message={
        "parts": [
            {"type": "text", "value": "Hello from Linq!"}
        ]
    },
)

print(f"Chat created: {chat.id}")
print(f"Message ID: {chat.last_message.id}")
```

The `from` value is the number provisioned to your account, and `to` contains the number(s) you're sending the message to in E.164 format (`+12223334444`, no spaces or dashes).

Linq returns the new chat and message, each with an ID you can use later for replies and threading. If the recipient has iMessage, your text lands as a blue bubble within seconds. That's how you know it's working.

### Step 3: Set up a webhook to receive replies

Your agent can send messages now, but it also needs to know when someone replies. A webhook handles that.

Instead of your code constantly checking Apple's servers for new iMessages, Linq pushes event data to a URL you own as soon as something happens, such as a user sending a message, a message being delivered, or a user typing. Your agent can then react (or respond) to those events in real time as they arrive.

Here's how to [set up a webhook](https://docs.linqapp.com/guides/webhooks/):

- **Build a public webhook endpoint.** Create an open endpoint on your backend server that accepts incoming `POST` requests over a secure `HTTPS` URL. During initial local development, a tunneling tool like ngrok or Linq's CLI can route live traffic to your laptop (`localhost`), so you can test before you deploy.
- **Create a webhook subscription in Linq.** Supply your public server URL to Linq, either through the Linq dashboard or the API endpoint. Then pick which events trigger a push. For AI agents, the one that matters most is `message.received`, but you can also listen to typing indicators, read receipts, or participant changes in group chats.
- **Specify a payload version.** Add a timestamp version to your subscription URL in the format `?version=YYYY-MM-DD`. This locks the payload format in place, so a future formatting change won't break your live agent. If you skip it, the subscription uses the latest version available at the time you created it.

> **Note:** When you register your webhook, Linq generates a signing secret that you should store securely on your server.

Every request Linq sends includes a cryptographic signature in its header metadata. Before your agent processes the payload, your code checks the raw, unparsed request body against your secret key to confirm that the request came from Linq. Linq provides official SDKs with built-in functions that automate this check for you.

### Step 4: Connect your LLM

When a user replies to your number, Linq sends the message to your server as a webhook immediately. Your server then passes that message to your preferred AI model, whether that's Claude, GPT, or your own custom model.

But you can't forward the message to the model on its own, because it won't know who the sender is or the conversation history. So, before you call the model, wrap the incoming message in context.

- **Look up the sender.** Linq attaches a unique ID or phone number to every incoming text. Your server uses it to check your database (Redis, Supabase, PostgreSQL) to see if that person has texted your agent before.
- **Bundle the history.** If a history exists, your server pulls the last 10–15 messages from your database, stacks them in order, adds the incoming text at the bottom, and hands the entire "bundle" to the LLM. Now the model can answer with the full conversation in view.
- **Save the new exchange.** Once the model generates a reply, your server does two things: it updates your database with the latest exchange and sends a reply to the user via Linq.

### Step 5: Make the communication feel real-time

A few seconds of model latency can make your agent feel robotic. To hide that delay and make your AI agent feel like a real human typing on an iPhone, you can use Linq's API to trigger read receipts and typing bubbles.

- **Send a read receipt.** The moment Linq tells your server that a new message has arrived, your server immediately sends a command back to Linq to mark it as read. On the user's iPhone, the status updates right away, so they know the agent is looking at the thread.
- **Turn on the typing bubble.** Next, your server sends a command telling Linq to switch typing indicators on. The familiar pulsing dots ("...") appear in the conversation window, like someone is typing a reply.
- **Let the model think.** While the dots are on the user's screen, your server passes the message to your LLM. The model generates a reply and sends it back to your server.
- **Turn the bubble off and reply.** Once the reply is ready, your server tells Linq to switch off the typing indicators (which clears the dots) and then delivers the message.

### Step 6: Test the full loop

Now that everything's connected, run the whole thing end-to-end. Remember the message you sent from Linq to your phone back in Step 2? This time, go the other way: from your phone, text the agent's number and confirm the reply comes back.

This round-trip test proves that the webhook fired, your server added conversational context and called the AI model, the read receipts and typing bubble showed, and the response came back to your phone as a blue bubble.

Don't call setup done until this full loop works.

## How to make your agent feel less like a bot

Once the basic loop works, the same Linq API opens up richer ways to interact, including:

- **Group chats.** Your agent can join group chats and act as a concierge for several people at once. For example, it can coordinate travel plans among friends, split a bill, or introduce students in a university cohort.
- **Rich media.** Your agent can [send and receive images, file attachments, and voice notes](https://docs.linqapp.com/guides/messaging/), not just text.
- **Tapbacks and reactions.** Your agent can react with a heart or thumbs-up. These give it a quick, wordless way to acknowledge something—like confirming that it got a request—without sending a new message.
- **[iMessage Apps](https://docs.linqapp.com/guides/messaging/imessage-apps/).** Your agent can send interactive cards that users can tap to do things like make payments, book flights, and listen to music, all inside the thread. There are many possibilities to be explored here.

## Why reliability and compliance matter with iMessage for AI agents

Apple guards iMessage tightly to keep users safe from spam and phishing. If your server experiences downtime or high latency, your AI agent may start misbehaving: sending broken messages, looping the same reply, or triggering carrier blocks. Any of these can make Apple ban the associated Apple IDs and phone numbers on the spot.

Furthermore, legal frameworks like the TCPA (Telephone Consumer Protection Act) and carrier guidelines strictly regulate automated messaging. Since iMessage connects directly to a user's personal phone number, failing to enforce explicit opt-ins, secure data handling, or automated opt-out keywords (like "STOP" or "UNSUBSCRIBE") exposes your business to heavy statutory fines and lawsuits.

Using a compliant platform like Linq ensures your infrastructure routes data securely and adheres to legal requirements. Linq offers:

- **SOC 2 Type II certification.** This provides verifiable proof that your customers' message data is handled in accordance with rigorous corporate security and privacy standards. Linq is the only iMessage API with this certification.
- **Contractual 99.95% uptime SLAs.** Linq backs its platform with explicit service level agreements (SLAs), guaranteeing [99.95% uptime](https://linqapp.com/s/example-apps/ai) so your AI agent is never unresponsive.
- **Ultra-low latency.** Outbound messages route with a P95 latency of under 120 milliseconds. This means when your LLM finishes generating a thought, Linq delivers it to the user's phone almost instantly.
- **Scale that's proven.** Linq is built for scale, successfully routing [over 150 million messages](https://linqapp.com/s/example-apps). Over 1,000 teams are already building on it.
- **Predictable, flat-rate pricing.** Instead of charging per message, Linq charges a flat monthly rate per phone line (which can save you thousands of dollars).
- **Secure encryption.** Your messages are encrypted end-to-end, so they stay private to you and your users. Even Linq can't read them.

## Ready to build your iMessage agent with Linq?

People trust iMessage. A blue bubble indicates the message is from a verified number, so when your AI agent texts a user there, they're more likely to open it and reply than they would to an email or an SMS from an unknown number.

Linq makes it easy to integrate your AI agent with iMessage. You can have it sending and receiving messages in the sandbox within minutes, and then transition to a permanent, custom-branded business line in a couple of days.

All of it runs on infrastructure that keeps your data secure and helps you stay compliant with the regulations governing automated messaging.

Ready to start? [Send your first iMessage with Linq's sandbox today](https://dashboard.linqapp.com/sandbox-signup/).

Turn your AI agent into an iMessage contact in 5 simple steps. A practical, developer-focused guide to setup with Linq's API.

iMessage for Agents: How to Integrate iMessage in 5 Easy Steps

AI is moving from chatbots that answer questions to agents that take real actions: booking the table, filling the cart, running the errand. More and more of that activity is happening in iMessage, where people already talk to each other and, increasingly, talk to agents built on Linq. An agent that lives in the thread should be able to finish the job in the thread, and finishing the job usually means getting paid.

Until now, it could not. An agent on Linq could hold a conversation, send rich messages, and act on a user's behalf, but the moment money entered the picture, it paused the conversation. Agents pasted a Stripe link, sent a payment handle, or pushed the user to a web page and hoped they came back. Every one of those steps is a drop off point.

Today we're launching **Agent Pay**, a way for agents to request payments directly inside an iMessage conversation. An agent creates a payment request and drops the checkout into the chat as a tappable payment card. The recipient taps it, an App Clip opens with the amount and line items, they checkout with Apple Pay and never leave the Messages app. Funds settle to your own Stripe account, and your server gets a webhook. Agent Pay is available to all Linq customers today.

## What agents can charge for

Agent Pay covers the three moments where money most often shows up in an agent conversation.

The first is paying for access to the agent. If your product gates access behind a subscription, usage, or a one-time unlock, the paywall can live directly in the thread instead of in an external link they’re likely to bounce from. An agent can now ask a new user to start a plan in the same conversation where they signed up.

The second is paying for what the agent does. When an agent shops, books, or orders on someone's behalf, it can settle the bill in place. Now, a grocery shopping agent can build the cart and request $40 to check out. A concierge agent can instantly collect a $25 deposit to hold a reservation. Agents finish the task in the same thread where it started.

The third is funding a wallet the agent can spend from. Some of the most useful agent behavior is autonomous: reorder groceries when they run low, grabbing the reservation the moment it opens, book the cheaper flight when the price changes. Those moments can't wait for a checkout tap. With Agent Pay, a user can top up a balance in the thread (ie. $100 for the week's errands) and the agent draws it down as it works, reporting back as it goes. Instead of approving every purchase, users give your agent a budget.

## How it works

Collecting a payment is two API calls and one webhook. You create a payment request with an amount and currency, and you get back a hosted `checkout_url`. You send that URL into the chat as a link message part, so it arrives as a card rather than a bare URL. The recipient pays, and you receive a `payment.succeeded` webhook.

This call creates the request:

```shell
curl -X POST https://api.linqapp.com/api/partner/v3/payment_requests \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 4000,
    "currency": "usd",
    "description": "Grocery order, Whole Foods",
    "metadata": { "order_id": "order_8675309" }
  }'
```

Payments run on Stripe Connect, so recipients can pay with Apple Pay, Visa, Mastercard, Amex, and any other method Stripe supports, and no card data touches your servers. Charges are created on your own connected account with you as the merchant of record, which means the funds, the payout schedule, and the customer relationship stay yours. Linq orchestrates the request and the checkout and is never in the funds flow. Refunds and disputes are handled in your Stripe Dashboard.

The checkout meets the recipient wherever they are. On a supported iPhone, the link opens an Agent Pay App Clip, a native checkout sheet with no install. On Android, on desktop, and on iPhones where the App Clip hasn’t activated yet, the same URL opens a web checkout. This means a single request works across every device.

## Building for agent commerce

Agents are becoming a category of software that people pay for and pay through, and the surface where that happens matters. The Messages app is the most-used surface on the phone, and it’s where Linq agents already live. Agent Pay is the first step in giving those agents a full commercial loop inside the conversation, alongside iMessage Apps, group chat, and the rest of the Partner API.

To start collecting, connect Stripe in your Linq dashboard and read the guide:

[**docs.linqapp.com/guides/payments**](https://docs.linqapp.com/guides/payments/)  

Agent Pay lets agents built on Linq request and receive payments directly inside an iMessage conversation. Pay with Apple Pay or any Stripe-supported method, and funds settle straight to your developer Stripe account.

Introducing Agent Pay: unlocking commerce for iMessage agents

You can now require dashboard members to sign in through your own identity provider. SSO governs dashboard login only, over SAML 2.0 or OIDC. API keys authenticate programmatic requests on a separate path and are unaffected, so an SSO problem can never touch your production traffic.

To enable it, contact us with the email domains you want to govern. Only users whose email matches an approved domain fall under your connection, so a member signing in as `alex@yourcompany.com` is in scope and a contractor on `alex@gmail.com` is not. An admin then selects your provider under Organization to SSO. Okta, Entra ID, Google, Auth0, ADP, and others are supported out of the box, with Custom SAML and Custom OIDC for anything not listed.

Every assertion we accept carries four required attributes, which you map during setup:

```json
{ "email": "email", "firstName": "firstName", "lastName": "lastName", "idpId": "NameID" }
```
*How assertion fields map to Linq user fields. A missing or misnamed attribute rejects the login.*

Two settings control enforcement. **Allow non-SSO logins** keeps existing methods available during rollout. **Enforce SSO-only** requires every member from an approved domain to authenticate through your IdP. Turning on enforcement logs out existing non-SSO sessions immediately, so if 200 people are working when you flip it, all 200 non-SSO sessions drop at once. Run Test sign-in first.

Two things to watch. Your signing certificate expiry is shown in the dashboard, and every SSO login fails the moment it lapses, so rotate ahead of the date. After any metadata or certificate change on the IdP side, re-run Test sign-in before relying on the connection. The Sessions list logs each attempt with email, name, status, and timestamp when you need to diagnose a failure.

Read the full guide in the [SSO docs](https://docs.linqapp.com/guides/platform/sso/).


Linq customers can now sign into their dashboard with SSO. 

Now available: Dashboard Single Sign-On

Lindy's founder, Flo Crivello, explains the problem his product solves with an analogy about flying. The most dangerous part of any flight is takeoff and landing. Cruising is safe and easy. A twelve-hour flight is fine because you spend it at altitude, and it would become miserable and dangerous only if you had to take off and land at every city along the way. Work is the same. "You want to cruise at 10,000 feet. You want to think strategically about your business and the things that really matter, but you're forced to take off and land at every city along the way. You got to send that email, and you got to jump on that meeting, and you got to follow up on this thing."

Lindy is the assistant meant to remove those takeoffs and landings. It triages your inbox, takes notes in your meetings, and handles the follow-ups afterward. Crivello wanted people to reach it the same way he reached his own human assistant, by text, because that is "the best way to communicate with your executive assistant." Delivering that over iMessage is the whole experience, and it is also the hardest part to operate. In December 2025, Lindy set out to build iMessage support in-house. Within a month they had built the same integration three times before moving it onto Linq, where it has run since. This is that story, drawn from Lindy's own account, [iMessage API: Three Rewrites, One Apple Ban, and What Actually Works](https://www.lindy.ai/blog/imessage-api-three-rewrites-one-apple-ban-and-what-actually-works).

## How Lindy got here

Lindy started with agents before most people were talking about them. The team began working on them in mid-2022, playing with the GPT-3 API, when they realized language models could be coaxed into taking actions and not only generating text. LangChain was a library blowing up on GitHub at the time, and the vision came together: an automated assistant for work, connected to all of your tools.

The models were not ready for that yet. GPT-4 had not shipped, and when it did it still could not run the full assistant reliably. So Lindy handed more and more control to the user: control the prompt, control which tool gets called, control which parameters get passed. Before long they had a no-code tool for people to build their own agents. When they looked at what people actually built, the answer was executive assistants. "That was the plan all along," Crivello says, "and now the models can actually support it." Lindy released its AI assistant in February, delivered over iMessage.

The name came from a teammate. The team had spent a long time brainstorming, and every candidate ran into an unavailable domain or a taken trademark. Someone in the room suggested "Lindy," after a colleague by that name. The domain was available for about seventy dollars a year. They took it.

## What Lindy built first

The first version was a Swift daemon on a Mac Mini in a Las Vegas data center. It watched the write-ahead log of the Messages SQLite database (`chat.db-wal`) for incoming texts and injected outgoing ones through Apple's private frameworks, with AppleScript as a fallback. It worked. It sent and received, handled attachments, and relayed events to Lindy's backend over webhooks.

The tell was in the health check. One field was `messagesAppRunning`, a boolean for whether Messages.app was still open on a machine in Nevada. That field is the real cost of the approach. A production feature's reliability depended on a desktop app staying launched.

## Why the first two versions did not hold

Two problems surfaced, and neither was about code quality.

The first was the bus factor. Only one engineer knew Swift. An iMessage bridge fails on physical hardware, and when it fails at 2am someone has to SSH in and debug a Swift process reading SQLite WAL files. Lindy migrated to BlueBubbles, an open-source JavaScript engine for the same job, so the whole team could maintain it. That move unlocked reactions, markdown formatting, edit and unsend, voice memos transcribed on the way in and generated on the way out, and inbound images fed to a multimodal model. Real progress, same hardware.

The second was that the hardware did not scale. Each phone number needed its own Mac Mini, its own iPhone, and its own Apple ID. The launch RFC estimated 100 to 500 messages per hour per Apple ID and planned for a few hundred messages per day. On launch day, real volume passed those numbers fast. A brand-new account sending high volume to a narrow set of recipients, with a lopsided send-to-receive ratio, tripped Apple's spam detection, and the account was banned after about half a day of live traffic. Buying another iPhone and provisioning another Mac would have reproduced the problem on a delay. Running a compliant fleet of phone numbers is a full-time operational job, and it was not the job Lindy set out to do.

## The rebuild on Linq

This is where Lindy moved to Linq. Linq runs the hardware and account layer that Lindy had been operating by hand: the Macs, the iPhones, the Apple IDs, number rotation, and the anti-spam strategy that keeps accounts healthy under load. It exposes iMessage, RCS, and SMS behind one REST API with webhooks, the same shape a developer already knows from Twilio or the WhatsApp Business API.

Because Lindy had built the integration twice already, they understood the routing, the webhook handling, and the attachment processing. What changed was ownership. They stopped running phones. The rebuild took about four hours. The new send path is small:

```javascript
try {
  return await trySendViaLinq(actor, identity, phoneNumber, message, attachments);
} catch (error) {
  logger.info("Linq send failed, falling back to SMS", { error });
}
return await sendViaSMS(actor, identity, phoneNumber, message);
```

Try Linq, fall back to SMS. Within days, Lindy had read receipts, attachments, voice memos, reply threading, and contact-card generation running on Linq, plus an onboarding flow where the user texts first so Apple sees a reciprocal conversation. The cleanup PR that removed the old bridge changed 76 files and was mostly deletions. The Mac Mini in Las Vegas was decommissioned.

## Making it feel like texting a person

With delivery handled by Linq, Lindy could spend its engineering time on the experience rather than the transport. Two small details did more for that experience than anything below the API line.

The first is the typing indicator. A request like "check my calendar for the week" can take a minute while the agent fetches and filters events. On the user's side, a minute of silence reads as broken. Lindy shows the native typing bubble while the agent works and drops it when the first reply is sent. The obvious alternative, sending "working on it" messages, would have spent messages that are better saved for real answers. The typing indicator costs none. It gives the user feedback for free.

The second is debouncing. People text in bursts: "hey," then "what's my day look like," then "weather in SF," three separate sends. Without buffering, that becomes three agent runs and three disconnected replies. Lindy waits three seconds after each inbound message, resets the timer on any new one, then bundles the burst into a single request. Shorter than three seconds drops the second message in a fast pair. Longer leaves a single-message user staring at nothing.

## What changed after the move

The move to Linq turned a fragile, hand-run bridge into a managed channel. There are no Mac Minis to keep alive, no Apple IDs to babysit, no manual number rotation, and no hand-built spam heuristics. Lindy now runs on eight load-balanced numbers with per-number daily caps and monitored send-to-receive ratios, all coordinated through a single API. Adding capacity is a provisioning step, not a hardware order.

That is the point of the whole exercise. Crivello wants people to feel "calm and in control," because "the quality of your work is a direct function of the mindset you have." Lindy delivers that feeling to users by removing the small takeoffs and landings from their day. Linq delivers the same thing to Lindy's engineers, by removing the messaging infrastructure from the list of things they have to fly. The team ships assistant features now, and the channel does what good infrastructure should do: it stays out of the way.

## Principles

**Do not run infrastructure that is not your product.** Lindy's product is an assistant, and every hour spent keeping Mac Minis alive was an hour not spent on it.

**Write for the bus factor, not the demo.** A bridge only one engineer can debug at 2am is a liability no matter how clean the code is.

**Buy the hard infrastructure and build the product.** A partner who runs iMessage full time will do it better than a team doing it on the side.

**Spend your message budget on the user, not on status.** A typing indicator beats three "still working" texts.

**Delete aggressively once a layer is owned elsewhere.** The best migration diff is mostly deletions.

Lindy tried to run its own iMessage infrastructure three times in a month, and ended up moving onto Linq's managed API to turn a fragile bridge into a reliable channel it no longer has to operate.

How Lindy shipped an AI assistant into iMessage

Most platforms put the burden of data retention entirely on the customer. We believe it should be part of the infrastructure. Today we are launching a new privacy tier on the Linq API built for the conversations that should never sit in storage: regulated workflows, PHI, financial data, identity verification, and any time you just want to keep data private. The tier ships with two independent features, **ephemeral messages** and **ephemeral attachments**, and it gives you something most messaging platforms make you engineer yourself: guaranteed content deletion on a fixed schedule, with zero content retention on our side. We keep the minimal pointers and deletion audit records compliance requires, and nothing you said. Turn it on for a single phone number, a set of numbers, or your whole partner account, and it applies automatically from that point forward.

Both features do the same thing at a high level. We keep the minimal pointers needed to support product behavior like reactions, and we delete your actual content. Message bodies, attachment bytes, formatting. All of it goes, on a fixed schedule, without you calling anything.

## Why we built it

You can already delete content yourself. DELETE /v3/messages/{messageId} and DELETE /v3/attachments/{attachmentId} hard-delete the content from Linq storage. That works when every delete call fires and lands.

But networks are messy. You might miss an event, a transient error drops a request, and a message gets stuck and never cleaned up. Building zero retention on top of per-object delete calls means one dropped request leaves content behind.

The ephemeral tier removes that dependency. The platform enforces deletion on a fixed timer. You do not have to call delete on every message and every attachment to get to zero retention. If you never make a single delete call, the content still expires.

## Ephemeral messages

Opt in by contacting your Linq support contact. When it is enabled, every message on the covered phone numbers gets a fixed 24-hour retention window. After that window, the platform permanently deletes the message from Linq storage. There is no per-message flag. Ephemerality is applied automatically based on your configuration.

The 24 hours run from message creation (created\_at), which is the moment the content first hits our servers. Not from delivery, not from read. We store the content encrypted (AES-256 at rest, TLS 1.2+ in transit) for that window, then revoke it. This holds for both outbound and inbound messages on the covered numbers.

Two scopes are available:

| Scope | Effect |
| :---- | :---- |
| **Partner-wide** | Every outbound and inbound message on every phone number under your account is retained for 24 hours, then deleted. |
| **Per phone number** | Only the specified phone numbers have their messages auto-deleted. The rest follow the standard message-retention policy. |

Here is how the ephemeral tier differs from the standard default:

| Aspect | Standard | Ephemeral |
| :---- | :---- | :---- |
| Retention | Retained per the standard message-retention policy | Hard backstop: 24 hours from when the message is created |
| After expiry | Message stays retrievable | Message is permanently deleted. GET /v3/messages/{messageId} returns 404 and it no longer appears in GET /v3/chats/{chatId}/messages |
| Content on expiry | N/A | Text, formatting, and attachment references are scrubbed. The message is gone, not blanked out |
| Cross-partner isolation | Enforced | Enforced |

A few properties of the window worth knowing:

- It is fixed at 24 hours from created\_at and cannot be configured per message.  
- It mirrors the ephemeral attachments 1-day backstop, so a message and any media it carries expire together.  
- Expiry is delivery-independent. The clock starts at creation, not at delivery or read.

And a few things you will observe at the API level:

- **No expiry timestamp is exposed.** API responses and webhook payloads do not include the deletion time. If you need it, compute created\_at \+ 24h yourself.  
- **No deletion webhook is sent.** There is no message.deleted event. A message simply stops being retrievable once its window passes.  
- **Delivery is unaffected.** Ephemeral messages send, deliver, and fire the usual message.sent, message.received and status webhooks exactly like standard messages. Only retention changes.

**Important**: Treat your application as the system of record. After 24 hours we cannot return the message to you. Not "will not," we cannot. If you need any part of it, persist it from the webhook payload at delivery.

```ts
// Capture message content at delivery time. After 24h, Linq cannot return it.
app.post("/webhooks/linq", (req, res) => {
  if (!verifyWebhook(SIGNING_SECRET, req.rawBody, req.headers)) {
    return res.status(401).end();
  }

  const event = JSON.parse(req.rawBody);
  if (event.type === "message.sent" || event.type === "message.received") {
    const msg = event.data;
    // Persist anything you need to retain. Reading it back later will 404.
    storeMessage({
      messageId: msg.id,
      chatId: msg.chat_id,
      parts: msg.parts,
      createdAt: msg.created_at,
    });
  }
  res.status(200).end();
});
```

Verify the signature before you trust the payload. Webhooks are signed following the [Standard Webhooks](https://github.com/standard-webhooks/standard-webhooks) spec. The signed content is {webhook-id}.{webhook-timestamp}.{body}.

```ts
import * as crypto from "crypto";

function verifyWebhook(secret: string, rawBody: string, headers: Record<string, string>): boolean {
  const msgId = headers["webhook-id"];
  const timestamp = headers["webhook-timestamp"];
  const signature = headers["webhook-signature"];

  const secretStr = secret.startsWith("whsec_") ? secret.slice(6) : secret;
  const keyBytes = Buffer.from(secretStr, "base64");
  const signedContent = `${msgId}.${timestamp}.${rawBody}`;
  const expected = crypto.createHmac("sha256", keyBytes).update(signedContent).digest("base64");

  return signature.split(" ").some((sig) => {
    if (!sig.startsWith("v1,")) return false;
    try {
      return crypto.timingSafeEqual(
        Buffer.from(expected, "base64"),
        Buffer.from(sig.slice(3), "base64"),
      );
    } catch {
      return false;
    }
  });
}
```

## Ephemeral attachments

Attachments have their own tier because the retention problem for files is different from the one for text. Opt in the same way, through your Linq support contact, at the same two scopes.

Attachment URLs come in two layouts depending on the tier:

| Tier | URL pattern | TTL |
| :---- | :---- | :---- |
| Persistent (default) | https://cdn.linqapp.com/attachments/partners/{partner\_id}/{attachment\_id}/{filename} | Long-lived |
| Ephemeral | Pre-signed URL pointing at the ephemeral prefix on cdn.linqapp.com | 15 minutes per signed URL. Re-fetch via the API for a fresh URL |

Behavior against the persistent default:

| Aspect | Persistent | Ephemeral |
| :---- | :---- | :---- |
| Download URL form | Long-lived CDN URL | Pre-signed URL with short TTL |
| Retention floor | Indefinite (until you call DELETE) | Hard backstop: 1 day. Even without an explicit DELETE, the platform removes the underlying bytes after 24 hours |
| URL re-fetch | Not required | Fetch via GET /v3/attachments/{attachmentId} for a fresh signed URL after TTL expiry |
| Cross-partner isolation | Enforced | Enforced |

**Outbound.** Pre-signed URLs are generated and last 15 minutes. After you dispatch a message, the URL and its contents are removed from our system 15 minutes after they were created. Past that point the content is revoked. It is architecturally impossible for that URL to resolve.

**Inbound.** We host the received media and hand you a single-use, short-TTL signed URL. Use it once: download the file and host it on your end. If the TTL expires before you fetch, get a fresh signed URL via GET /v3/attachments/{attachmentId}. The bytes are removed from Linq servers on the 1-day backstop regardless.

```go
func handleInboundMedia(ctx context.Context, part Part, attachmentID string) error {
	// part.URL is the short-TTL signed URL from the webhook.
	resp, err := http.Get(part.URL)
	if err != nil {
		return err
	}
	defer resp.Body.Close()

	if resp.StatusCode == http.StatusNotFound {
		// TTL expired. Fetch a fresh signed URL, then retry.
		meta, err := client.Attachments.Retrieve(ctx, attachmentID)
		if err != nil {
			return err
		}
		resp, err = http.Get(meta.DownloadURL)
		if err != nil {
			return err
		}
		defer resp.Body.Close()
	}

	return storeBytesInYourOwnStorage(attachmentID, resp.Body)
}
```

Inbound media over webhooks uses the same URL layout your outbound sends produce, so the URL you store and the URL you build look identical. No special casing in your client. If the receiving phone is opted in to ephemeral, the url in the webhook is a short-TTL signed URL rather than a long-lived one.

If you want to remove an attachment before the backstop, DELETE still works and is irreversible:

```
DELETE /v3/attachments/{attachmentId}
Authorization: Bearer <your_api_key>
```

A 204 No Content means the bytes are gone. There is no undelete. The message part that referenced the attachment is preserved with no attachment reference, and any previously delivered webhook keeps its original URL string, but downloads from that URL return 404 going forward.

## How the two tiers interact

The features are independent. You can run ephemeral attachments without ephemeral messages, or both together.

| Data | Persistent tier | Ephemeral tier |
| :---- | :---- | :---- |
| Attachment bytes | Retained until you DELETE | Auto-removed after 1 day, also removable via DELETE |
| Attachment metadata (id, filename, mime type, size) | Retained until you DELETE | Removed alongside the bytes |
| Message body and parts | Retained per message-retention policy | Retained per message-retention policy, unless the line also has ephemeral messages enabled, in which case the message and its parts are deleted 24 hours after creation |
| Audit log of deletions | Retained per platform retention policy | Retained per platform retention policy |

## When to use it

We recommend using the ephemeral tier when:

- You have a compliance requirement that the platform must not retain content beyond a short window  
- The conversation is high-sensitivity: PHI, financial, identity verification  
- Your application is the system of record. You capture what you need from the delivery webhook in real time and do not read history back from Linq later  
- You're running agents that generate message volume at a scale that prohibits a strategy of manual delete calls on every message

The design assumption is that you hold the durable copy. Linq delivers the message and the media, fires the webhook, and then gets out of the way. Anything you do not persist at delivery time is gone in 24 hours.

## Enabling ephemeral messaging

You can toggle on ephemeral messaging partner-wide from your Linq dashboard’s settings.

Full reference:

- [Ephemeral Messages (Privacy Tier)](https://docs.linqapp.com/api/#ephemeral-messages-privacy-tier)  
- [Ephemeral Attachments (Privacy Tier)](https://docs.linqapp.com/api/#ephemeral-attachments-privacy-tier)



Linq is launching an ephemeral messaging privacy tier on its API that automatically hard-deletes message content after 24 hours and attachment bytes within a day, giving partners platform-enforced zero retention for sensitive conversations without relying on manual delete calls.

Introducing ephemeral messaging: content deletion enforced by Linq

Most teams building on Linq treat the conversation as the whole product. The user texts your number, your agent replies, and everything the agent knows lives inside the thread. That is a fine default. But the thread is a text-only surface. It is bad at complex state: running totals, current status, the thing you want the user to glance at without scrolling back through twenty messages.

The Dynamic Island handles that well. It is persistent and always at the top of the screen. It holds one small piece of live state and updates it in place. Running both surfaces at once gives your agent a second channel that costs the user nothing to read.

One of our partners, [BodyBuddy](https://bodybuddy.app), shipped the first version of this we have seen in production. This post covers how the pattern works, why it depends on being iMessage-native, and what you need on both sides to build it.

## What BodyBuddy built

[BodyBuddy](https://bodybuddy.app) is an AI health accountability coach you text with. You connect HealthKit through their iOS app, and from then on the coaching happens over iMessage. Real texts from your coach, no notification spam. They launched at the start of the year and have run over 200k coaching texts since.

In their latest release, while you are texting the coach, your calories, meals, and current state stay live at the top of the screen in the Dynamic Island. Log a meal in the conversation and the calorie ring in the Island moves. The chat carries the conversation. The Island carries the state the conversation produces. Those side effects used to be invisible unless you scrolled.

Here it is running. The conversation is in Messages, and the Island stays live above it the whole time.

Nobody had done this before because of a platform detail. That detail is the whole point.

## Why this depends on iMessage

A Live Activity renders in the Dynamic Island only when its owning app is not in the foreground. That is the normal case. You start a workout in a fitness app, background it, and the Island keeps the timer alive while you do other things. Reopen the app and the Island collapses, because the app is now on screen and owns the full display.

A conventional chat app cannot use this. If BodyBuddy's chat lived on a screen inside their own app, that screen would be in the foreground the whole time the user is chatting. Their own Live Activity would not show. The user would see the chat and nothing else.

BodyBuddy chats over iMessage. So the foreground app is Messages, and the BodyBuddy app is backgrounded. Its Live Activity owns the Island for the entire session. The user reads the conversation in Messages and the ambient state in the Island at the same time, from two different apps. Being iMessage-native, through Linq, is what makes the surface available at all.

## The architecture

There are two independent channels to the same user, joined in your backend.

| Channel | Owns | Mechanism |
| :---- | :---- | :---- |
| Conversation | The back-and-forth | Linq: inbound `message.received` webhooks in, `POST /v3/messages` out |
| Ambient state | The glanceable status | ActivityKit: an APNs Live Activity push updates a `ContentState` your widget renders |

Linq never touches the Dynamic Island. ActivityKit never touches the thread. Your server is the join point. Here is the end-to-end loop for a single inbound text.

1. The user texts your Linq number. Linq fires a `message.received` webhook at your endpoint.  
2. Your agent runs. It reads the message, updates its model of the user (logs the meal, recomputes the calorie total, advances the streak), and decides on a reply.  
3. You send the reply back over Linq with `POST /v3/messages`.  
4. You send an ActivityKit update push to APNs, carrying the new `ContentState`, targeted at that user's Live Activity push token.  
5. iOS re-renders the Live Activity in place. The app is backgrounded behind Messages, so the update lands in the Dynamic Island the user is already looking at.

Steps 3 and 4 are independent and can fire in parallel. The reply is the conversation. The push is the ambient state.

## The identity join

Everything above is standard plumbing. The one piece that is yours to solve is correlating a Linq handle with an ActivityKit push token. It sits between the two systems and neither one owns it.

The inbound webhook identifies the user by phone number. From the `message.received` payload:

```json
{
  "event_type": "message.received",
  "data": {
    "chat": { "id": "8f392755-...", "is_group": false },
    "direction": "inbound",
    "sender_handle": { "handle": "+12025559876", "service": "iMessage" },
    "parts": [{ "type": "text", "value": "just had a chicken bowl, ~600 cal" }]
  }
}
```

`sender_handle.handle` is your key. The app supplies the other half. When a user onboards through the BodyBuddy app (granting HealthKit, signing in), you already have their phone number and their app account. Store that mapping. When the app starts a Live Activity, register its push token against the same account:

```swift
let activity = try Activity.request(
    attributes: CoachAttributes(userID: currentUser.id),
    content: .init(state: initialState, staleDate: nil),
    pushType: .token
)

for await tokenData in activity.pushTokenUpdates {
    let token = tokenData.map { String(format: "%02x", $0) }.joined()
    await api.registerLiveActivityToken(token, for: currentUser.id)
}
```

Now your backend has `phone number → app user → live-activity push token`. When a webhook arrives, resolve the handle to the user, look up their active token, and you know which Island to update. Verify the webhook signature before you trust any of it. Linq signs with the [Standard Webhooks](https://github.com/standard-webhooks/standard-webhooks) spec, the same as everywhere else in the API.

## The widget: the DynamicIsland struct

The Island layout is a `DynamicIsland` inside your `ActivityConfiguration`. You define the same state in up to four presentations and the system picks one based on context. Compact when your activity is the only one live, minimal when it is sharing the Island, expanded on long-press.

```swift
ActivityConfiguration(for: CoachAttributes.self) { context in
    // Lock Screen / banner presentation
    CoachLockScreenView(state: context.state)
} dynamicIsland: { context in
    DynamicIsland {
        // Expanded (long-press), up to four regions
        DynamicIslandExpandedRegion(.leading) {
            CalorieRing(consumed: context.state.calories, goal: context.state.goal)
        }
        DynamicIslandExpandedRegion(.trailing) {
            Label("\(context.state.streak)🔥", systemImage: "flame.fill")
        }
        DynamicIslandExpandedRegion(.bottom) {
            Text(context.state.lastMeal)
        }
    } compactLeading: {
        CalorieRing(consumed: context.state.calories, goal: context.state.goal)
            .frame(width: 22)
    } compactTrailing: {
        Text("\(context.state.calories)")
    } minimal: {
        CalorieRing(consumed: context.state.calories, goal: context.state.goal)
    }
    .keylineTint(.green)
    .widgetURL(URL(string: "bodybuddy://today"))
}
```

Two configuration calls are worth knowing. `keylineTint(_:)` tints the border glow around the Island so your activity is recognizable at a glance. `widgetURL(_:)` sets where a tap goes. Deep-link it into the relevant screen of your app so the Island doubles as a shortcut back in. `DynamicIsland` also exposes `contentMargins(_:_:for:)` if the defaults crowd your layout.

Keep the compact and minimal views to a single glanceable number or ring. They are a few points wide. Put detail in the expanded view, which appears only on a deliberate long-press.

## The server: the update push

When your agent finishes handling a webhook, push the new state to APNs. It is a normal HTTP/2 request with Live-Activity-specific headers:

```
apns-topic: <your-bundle-id>.push-type.liveactivity
apns-push-type: liveactivity
apns-priority: 10
```

```json
{
  "aps": {
    "timestamp": 1751990400,
    "event": "update",
    "content-state": {
      "calories": 1240,
      "goal": 2100,
      "streak": 6,
      "lastMeal": "Chicken bowl · 600 cal"
    },
    "stale-date": 1751994000
  }
}
```

The `content-state` must match the `ContentState` your `ActivityAttributes` declares. Same fields, same types, or the update is dropped. `event` is `update` here. It is `end` when you want to tear the activity down, for example when a texting session goes idle, with an optional `dismissal-date`. Set a `stale-date` so the Island visibly goes stale if your backend goes quiet, rather than showing numbers the user cannot trust.

To make the Island appear the moment a session starts, without the user reopening the app, use push-to-start (iOS 17.2+). Register the app's `pushToStartToken` the same way you register the update token, then send a push with `event: "start"` that includes `attributes-type`, `attributes`, and the initial `content-state`. The first text of a session can spin the Island up server-side, and the last one can tear it down.

## When to use it

This pattern earns its keep when your agent produces state the user wants to watch accumulate over a session. Calories and streaks here, but equally an order total as items get added, a delivery ETA, a balance, points remaining, or a checklist burning down. If the user would otherwise scroll the thread to reconstruct a number, pin it instead.

Skip it for one-shot Q\&A or anything where the state is just the last message. The thread already shows that. The Dynamic Island is complementary not a place where you duplicate the last message.

It only pays off on an iMessage-native build. That is the one configuration where your ambient surface and your conversation surface are visible at the same time. If your users live inside your own app's chat UI, the Island collapses the moment they open it, and you have built a channel nobody can see. Delegating the thread to Messages, through Linq, is what frees up the rest of the screen for the Island.

## Reference

- Linq: [Webhook Events](https://docs.linqapp.com/guides/webhooks/events), [Sending Messages](https://docs.linqapp.com/guides/messaging/sending-messages), [Webhooks overview](https://docs.linqapp.com/guides/webhooks)  
- Apple: [`DynamicIsland`](https://developer.apple.com/documentation/widgetkit/dynamicisland), [Displaying live data with Live Activities](https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities), [Starting and updating Live Activities with ActivityKit push notifications](https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications)

How to give your iMessage agent a live Dynamic Island by wiring Linq inbound webhooks to ActivityKit push updates.

Putting your iMessage agent in the Dynamic Island

The largest consumer companies in the world are building on our API, and they all hit the same wall at scale: at any given point in time, which Linq number is most optimal to assign to a user?

Today we’re taking on all the work involved in answering that question through two new endpoints in our API. These endpoints take routing, health checks, failover, and number migration off your plate. You send a message to a recipient, and we pick the line, create or reuse the chat, and route around numbers that can't send.

Load balancing has been a rough edge in our API since the beginning. If you send at any real volume, you’ve experienced the pain. You spread traffic across a pool of lines, watch for numbers that get throttled or flagged, and migrate conversations off the bad ones before your delivery rates fall. You track which chat lives on which line, and you keep a table of chat IDs so replies land in the right place. None of this is your actual product. It is undifferentiated work that every high-volume sender rebuilds. So we built it for you.

Here is how the two endpoints work and when to use each.

## The two endpoints

`GET /v3/available_number` tells you the best line to send from right now.

`POST /v3/messages` sends a message without asking you for a `from` number at all.

Most integrations only need the second endpoint. 

The first is there for the cases where you need a number to render before you send anything, like a click-to-text button or a contact card on a landing page.

## Getting a line to display: `available_number`

`available_number` returns the healthiest line in your pool at a point in time, in E.164 format. Health here is a function of internal line reputation plus rolling volume over the last hour and the last 24 hours.

```
curl https://api.linqapp.com/api/partner/v3/available_number \
    -H "Authorization: Bearer $LINQ_API_V3_API_KEY"
```

```json
{
  "phone_number": "+12025551234",
  "vcf_url": "https://s3.us-east-1.amazonaws.com/linq-attachments/vcf/9716d5c5/12025551234.vcf?X-Amz-Signature=..."
}
```

Two things to know about it.

It is advisory. The call does not reserve the line or change any selection state. If you want to guarantee a chat starts on the number you just got back, pass that `phone_number` as `from` when you create the chat. You can also pass a `to` set to the endpoint. When you do, and an existing chat with those recipients is already on a healthy line, the response reuses that line instead of picking a fresh one.

It also returns a `vcf_url`. That is a time-limited link to a vCard for the selected line. The card carries the line's name and photo, sets the selected number as the primary `TEL`, and lists your other healthy lines as backups. Share it so recipients can save the number as a contact. The backups matter later: if you have to move a recipient to a different line, the number is already in their contacts, so the transition doesn't look like a stranger texting them. The link expires, so call the endpoint again to mint a fresh one.

## Sending without a `from`: `POST /v3/messages`

This is the endpoint that removes the load balancing work. You give it recipients and a message. You do not give it a `from` number, and you do not give it a chat ID. It resolves both.

```
curl -X POST https://api.linqapp.com/api/partner/v3/messages \
    -H "Authorization: Bearer $LINQ_API_V3_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "to": ["+12025550147"],
      "message": {
        "parts": [
          { "type": "text", "value": "Your table for 4 is confirmed for 7:30 tonight." }
        ]
      },
      "continuation_message": {
        "text": "Confirming your table for 4 at 7:30 tonight."
      }
    }'
```

`to` is an order-independent set of handles, either E.164 numbers or email addresses. One handle is a direct chat. Multiple handles is a group chat. The set identifies the chat, so you never look up or store a chat ID to continue a conversation.

The response tells you exactly what happened.

```json
{
  "chat_id": "b1c0a2d4-...",
  "created_new_chat": true,
  "from": "+12025551234",
  "from_selection": {
    "reason": "new_best_number",
    "reused_existing_chat": false
  },
  "is_group": false,
  "message": {
    "id": "9f3e...",
    "created_at": "2026-07-08T15:04:05Z",
    "delivery_status": "queued",
    "parts": [ ... ]
  }
}
```

The endpoint always responds `202 Accepted`. Chat creation is incidental to the send.

## How the line gets chosen

`from_selection.reason` reports which of three branches ran.

`reused_active_chat`. A chat with exactly these recipients already exists, and the line it lives on is healthy. The message goes into that chat on its existing line. This is what keeps a conversation on one number across many sends, so the whole exchange stays in a single thread for the recipient.

`new_best_number`. No chat exists for this recipient set. We create one on the best available line, using the same health and volume signals as `available_number`.

`failover_flagged`. A matching chat exists, but its line has been flagged and can no longer send. This is the case you used to handle by hand. We create a new chat on a fresh best line, abandon the flagged one, and set `previous_chat_id` on the response. If you supplied a `continuation_message`, its text is sent as the single message instead of `message`. That is the opener in the curl above. The recipient is now on a new number, so a short reintroduction usually reads better than replaying the original content. Exactly one message is sent on this branch either way. The `continuation_message` is ignored on the other two branches.

You do not choose the branch. You send the same request every time and read `reason` if you care what happened.

## Scaling and migration come for free

Add a line to your pool and it enters rotation automatically. You do not register it anywhere or change your send code. As your volume grows, more of the pool absorbs it. When a number degrades, failover moves new sends to a healthy line and, with `continuation_message`, does it with copy you wrote for that situation. You are no longer writing migration jobs.

## A few details worth knowing

The `message` object carries `parts` (text, media, or link), plus optional `effect`, `preferred_service` (`iMessage`, `RCS`, or `SMS`), `idempotency_key`, and `reply_to`. A text part goes up to 10,000 characters. A `link` part must be the only part in the message.

The first message on a chat may contain a link, including on a newly created chat. Be careful with it. Sending a link as the very first message on a freshly selected line raises that line's flagging risk. It is allowed, not recommended.

Voice memos are not supported here. To send an iMessage voice-memo bubble, use `POST /v3/chats/{chatId}/voicememo` with a known chat id.

Pass an `Idempotency-Key` header, or `message.idempotency_key`, to make retries safe.

## When to use it

If you run more than five lines, use both endpoints. Migration and load balancing are where most of the value is, and they only matter at scale. If you run one or two lines, `POST /v3/messages` is still worth adopting on its own. You stop managing chat IDs and stop maintaining separate create-chat and send-message calls. One endpoint creates the chat when it needs to and appends to the existing one when it can.

The reference docs are at [available\_number](https://docs.linqapp.com/api/resources/available_number/methods/retrieve) and [messages](https://docs.linqapp.com/api/resources/messages/methods/create).

Load balancing has moved from your code to ours. Two new endpoints handle line selection, health checks, failover, and number migration automatically.

Just hit send: Introducing managed load balancing 

Linq developers can now build **iMessage Apps**: interactive mini-apps that run inside a Messages conversation.

Users can shop, play games, date, book appointments, fill out forms, or complete other workflows without leaving the thread. There is no deep link to an external browser. There is no "tap here to finish in the app." The experience renders inside the bubble, where the conversation is already happening.

The thread is the most-used surface on the phone. Until now, the best API-level option was to drop a link into a conversation and hope the user followed it somewhere else. iMessage Apps remove that handoff. The action happens in the message.

## What you can build

An iMessage App is a tappable card that opens an interactive experience in place. Here are a few examples.

**Games.** Send a move, redraw the board, and run a full turn-based match inside the thread. Since a card can be updated in place, a live game session becomes a sequence of updates to the same bubble.

**Dating.** Profiles, prompts, and matches can live where people are already talking. The interaction stays in the conversation instead of sending the user back to a standalone app.

**Payments.** Send a checkout or request-to-pay as a card. The recipient can complete it in the thread, without a redirect or copied payment link.

**Tickets.** RSVPs, event passes, and order status can update as state changes. A card can move from "Going / Not going" to a confirmed ticket, or from *Reserved* to *Confirmed*, in the same bubble.

**Flight booking.** Surface a fare, let the user pick and confirm, then update the card to a boarding pass in the same conversation.

**Music.** Drop a track into the thread and let people play it inline. The card is a player, not a link to another app.

These are examples, not a fixed menu. If your product has an interactive moment, it can happen inside the message.

## How it works

iMessage Apps are sent as a new message **part** with `type: "imessage_app"`. This replaces the `text`, `media`, and `link` parts you already use.

The card becomes your app inside the bubble. An installed Messages extension draws rich, interactive content from a URL you provide.

### Sending a card

Send a card as the first message in a new chat with **Create Chat**, or post the same part into an existing chat with **Send Message**:

```bash
curl -X POST https://api.linqapp.com/api/partner/v3/chats \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "+12052535597",
    "to": ["+12052532136"],
    "message": {
      "parts": [
        {
          "type": "imessage_app",
          "app": {
            "name": "Example App",
            "team_id": "A1B2C3D4E5",
            "bundle_id": "com.example.app.MessageExtension"
          },
          "url": "https://app.example.com/card?id=abc123",
          "fallback_text": "Open in Example App",
          "layout": {
            "caption": "Example App",
            "subcaption": "You said: hello"
          }
        }
      ]
    }
  }'
```

Three details matter before your first send.

### 1. The app identity is the rendering key

The `app` object, specifically `team_id` and `bundle_id`, tells Messages which extension renders the card. The card is drawn by that extension, so you usually pass your own app's identity.

`app_store_id` is optional. If you set it, recipients who do not have the app installed see a **Get the app** affordance.

One common failure mode: an unrecognized identity silently renders as plain text. If `team_id` and `bundle_id` do not match a Messages extension installed by the recipient, the card falls back to your caption text with no error. If your card only shows text, verify the identity against your shipping app.

### 2. You control captions; the app controls the image

The `layout` object defines the text you can put directly on the card:

| Field                 | Position                       |
| --------------------- | ------------------------------ |
| `caption`             | top-left, bold primary label   |
| `subcaption`          | left, below `caption`          |
| `trailing_caption`    | top-right                      |
| `trailing_subcaption` | right, below `trailing_caption` |

At least one field must be set, or the card renders as an empty bubble.

There is no image field. The photo, icon, and interactive UI come from your app's extension, drawn from the `url`. Messages treats the `url` as opaque. Your extension interprets it and renders from it. Change the `url` to change what the card shows.

If you need an image that everyone can see, regardless of whether they have your app installed, use a rich link or media attachment instead. That is a different tool.

Install state determines what the recipient sees:

| Recipient state | Result |
| ---------------- | ------ |
| Has your app | The extension renders a rich card from your `url`. |
| Does not have your app | The recipient sees your `layout` captions, plus the **Get the app** affordance if you set `app_store_id`. |

### 3. Cards update in place

A delivered card can be replaced in place by referencing the original message. This is the primitive behind a game move redrawing the board, or an order changing from *Reserved* to *Confirmed*.

```bash
curl -X POST https://api.linqapp.com/api/partner/v3/messages/{messageId}/update \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://app.example.com/card?game=7f3a&move=2",
    "fallback_text": "Score update",
    "layout": { "caption": "Score: 2 - 1" }
  }'
```

Rules to account for:

- The update replaces the delivered card instead of posting a second bubble.
- Only `url`, `fallback_text`, and `layout` can change.
- The app identity is fixed for the life of the card.
- The card must already be **delivered**.
- A `409` means you should retry after the `message.delivered` webhook.
- Each update is a **new message** with its own ID and lifecycle.
- To update the card again, reference the new message ID.

You can also receive cards. Inbound messages include an `imessage_app` part in the `message.received` webhook. Your handler can read the app identity, `url`, and `layout` from a card the user sends you.

## Constraints to plan around

iMessage App parts have stricter rules than other message parts.

- **iMessage only.** They never fall back to SMS or RCS.
- **No mixed fallback request.** If you request SMS or RCS alongside an iMessage App part, the send is rejected with `2018`.
- **Async failure for unreachable recipients.** If the recipient is not reachable over iMessage, the send is accepted and then fails asynchronously with a `4005` `message.failed` webhook. Check capability before sending.
- **Must be the only part.** An `imessage_app` part cannot be combined with `text`, `media`, or `link` in the same message.

## Get started

The full guide covers send, receive, update, webhooks, and capability checks:

**[docs.linqapp.com/guides/messaging/imessage-apps](https://docs.linqapp.com/guides/messaging/imessage-apps/)**

Give your agents an interactive surface inside iMessage, where users can complete workflows without leaving the conversation. This post covers how Linq developers can send, render, update, and receive iMessage app cards, with the constraints to plan around in production.

Supercharge Your Agents With iMessage Apps

Most messaging products treat group chats as larger 1:1 conversations. That misses the point. Group chats are where coordination happens: friends plan, matchmakers introduce people, concierges loop in vendors, and deals move forward. If you are building an agent for anything social or multi-party, the group thread is not a secondary feature. It is the product surface.

Linq's v3 API treats group chats as first-class objects over iMessage and RCS, with display names, icons, participant management, and webhooks for membership changes. This post covers what that makes possible, how to implement it, and the main product problem teams hit when they add an agent to a group: deciding when the agent should speak.

The examples at the end come from the open-source [Linq AI agent example](https://github.com/linq-team/ai-agent-example).

## Group chats need different product logic

A 1:1 agent has a simple turn-taking model. Every inbound message is addressed to the agent, so the agent replies to everything.

That assumption fails as soon as a third participant joins. In a group, most messages are humans talking to each other. The core product question changes from "what should the agent say?" to "should the agent say anything?"

That shift enables products that cannot work in a 1:1 thread.

**Matchmaking and introductions.** [Ditto](https://ditto.ai/) describes itself as "your college matchmaker." It learns your type, scans the pool, and texts you a ready-to-go date over iMessage. No swiping, no long pre-date chat. Ditto reports 12,000+ dates delivered, with 70% of users getting a first date within two days.

For a matchmaker, the natural next step is the introduction itself. Put both matches in a group thread, set the group photo to a custom date card, let the agent warm up the conversation, suggest a time and place, then step back. Ditto already describes an agentic system of expert agents for analysis, matchmaking, posting, and scheduling. The group thread is where the scheduler and concierge agents become useful.

**Concierge and coordination.** A travel or events agent can pull a customer, a vendor, and itself into one thread to handle logistics. The agent answers when asked, stays quiet while humans work through details, and returns to confirm the final plan.

**Group commerce and planning.** Splitting a bill, planning a trip, and coordinating a gift all need structured work inside a social conversation. The agent can handle totals, scheduling, reminders, and follow-ups without taking over the thread.

**Community and cohort bots.** A class, club, or founder cohort can have an assistant that answers direct questions and reacts to milestones without replying to every message.

All of these products depend on the same requirement: the agent has to be a good group chat participant. If it talks too much, people mute it. If it talks too little, it feels broken. If it replies to one person but ignores another asking the same thing, users lose trust.

That consistency is the engineering problem.

## Implementing group chats on Linq

The examples below use Linq's Partner v3 API. Full endpoint specs are in the [Chats API reference](https://docs.linqapp.com/api/resources/chats), and the [group chats guide](https://docs.linqapp.com/guides/chats/group-chats/) is the canonical source for current constraints.

### Create a group

A group chat is any conversation with three or more participants. Create one by sending the first message to multiple recipients:

```bash
curl -X POST https://api.linqapp.com/api/partner/v3/chats \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "+12223334444",
    "to": ["+15556667777", "+18889990000"],
    "message": {
      "parts": [
        { "type": "text", "value": "Welcome to the group!" }
      ]
    }
  }'
```

Design around two constraints from the start:

- **No links in the first outbound message.** `link` parts and text parts containing URLs are rejected on `POST /v3/chats`. Send a clean opening message, then follow up with a [rich link preview](https://docs.linqapp.com/guides/messaging/rich-link-previews) using the returned chat ID. This matters for matchmaker and concierge flows, where the first instinct is often to lead with a link.
- **Recipient caps vary by delivery path.** The `to` array supports up to **31 recipients**, but SMS/MMS fallback depends on carriers. Most cap group texts around **20** recipients, and some go as low as **10**. Plan for the strictest path your message may take.

### Name it and give it an icon

Display names and icons are group-only. This is where a matchmaker can set a custom date card as the group photo, or a concierge can brand the thread:

```bash
curl -X PUT https://api.linqapp.com/api/partner/v3/chats/{chatId} \
  -H "Authorization: Bearer $LINQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Team Discussion",
    "group_chat_icon": "https://example.com/group-icon.png"
  }'
```

`group_chat_icon` must be a publicly accessible HTTPS URL. Calling this endpoint on a 1:1 chat returns [error `1006`](https://docs.linqapp.com/error/codes/1xxx/1006), because names and icons only apply to groups.

### Manage participants

Adding and removing participants is supported on **iMessage group chats only** today. The API enforces two rules:

- A group must always have **at least 3 members**. You cannot remove someone or leave yourself if that would drop the group below three.
- Leaving is one-way. Once your number leaves, you lose access unless an active participant adds you back. Recreating a chat with the same people creates a new, separate chat. A [`participant.removed`](https://docs.linqapp.com/api/resources/webhooks) webhook fires after the leave is processed.

See the [add](https://docs.linqapp.com/api/resources/chats/subresources/participants/methods/add) and [remove](https://docs.linqapp.com/api/resources/chats/subresources/participants/methods/remove) participant references for the full schema.

### Account for missing 1:1 features

Group chats do not support **typing indicators, delivery receipts, or read receipts**. If your 1:1 experience relies on "agent is typing..." or read state, use a different affordance in groups. Do not expect those events to fire.

### Wire up webhooks

Chat creation, group detail updates, and participant changes all fire [webhook events](https://docs.linqapp.com/guides/webhooks/events#chat-events). Your inbound message handler should branch on group vs. 1:1 from the first event, because the response logic is different.

## Making an agent consistent in a group

Teams usually frame group-chat inconsistency as an agent framework problem. A customer put it this way:

> "Our agent is struggling to be consistent in responding to all users. I think it's an agentic framework issue. Any tips with that, or resources?"

The better framing is architecture. The fix is to separate the decision to respond from the generation of the response.

### Why one model call fails

The naive design sends every inbound group message to the main model and asks it to decide whether to respond in the same call where it writes the reply.

That fails in predictable ways:

- **The behavior varies.** A generative model asked to judge and act in one pass will make that judgment differently across runs. Two people can ask the same thing, and the agent may answer one but ignore the other.
- **The agent talks too much.** Models are optimized to be helpful. They often reply to messages that were meant for another human.
- **It is slow and expensive.** Busy groups create many messages the agent should ignore. Running the full model on each one wastes latency and tokens.
- **It can loop.** Without an explicit action gate, agents can fall into reaction spirals like repeated tapbacks.

The root issue is that "should I respond?" and "what should I say?" have different cost, latency, and consistency requirements. They should not be handled by the same model call.

### Use a cheap classifier as the gate

Patrick Sullivan, Linq's CTO, solved this in the [open-source agent example](https://github.com/linq-team/ai-agent-example):

> "The way I solved it was to add in a simple, fast, cheap model to determine if it should be responding to a message."

The pipeline has two stages.

Stage one is a small, fast, cheap model, Claude Haiku, with one job: classify each incoming group message as `respond`, `react`, or `ignore`.

Stage two is the full Sonnet agent. It only runs when the stage-one verdict is `respond` or `react`. The expensive model no longer decides whether to speak. It only runs after the system has already decided that speaking is appropriate.

The classifier makes a narrow, repeated judgment in about 20 output tokens. That makes it cheaper, faster, and easier to tune than the main agent.

Here is the classifier, lightly trimmed from [`src/claude/client.ts`](https://github.com/linq-team/ai-agent-example/blob/c4d10a72e7397f1d1d7be8f9a67261bd6f674072/src/claude/client.ts#L745):

```ts
export type GroupChatAction = 'respond' | 'react' | 'ignore';

export async function getGroupChatAction(
  message: string,
  sender: string,
  chatId: string
): Promise<{ action: GroupChatAction; reaction?: Reaction }> {
  // Pull the last few messages so the classifier has context
  const history = await getConversation(chatId);
  const recentMessages = history.slice(-4); // last 2 exchanges
  const contextBlock = /* format recent messages with sender handles */;

  const response = await client.messages.create({
    model: 'claude-haiku-4-5',          // fast and cheap, not the main agent model
    max_tokens: 20,                      // it only needs to emit one short verdict
    system: `You classify how an AI assistant "Claude" should handle messages in a group chat.

IMPORTANT: BIAS TOWARD "respond" - text responses are almost always better than reactions.
Only use "react" for very brief acknowledgments where a text response would be awkward.

Answer with ONE of these:
- "respond" - Claude should send a text reply. USE THIS BY DEFAULT when:
  * They asked Claude anything
  * They mentioned Claude (or misspelled it - cluade, cloude, cladue, claud, etc.)
  * They mentioned "AI", "bot", "assistant", or "Sullivan"
  * They're talking to Claude or continuing a conversation
  * It's a follow-up to Claude's message
  * You're unsure - default to respond
- "react:love" | "react:like" | "react:laugh" - ONLY for brief acknowledgments where text
  would be weird (a simple "thanks!" or "lol"). Do NOT overuse reactions.
- "ignore" - Human-to-human conversation not involving Claude at all

ANTI-REACTION-LOOP: If you see reactions in recent context, prefer "respond" to break the pattern.
MISSPELLING TOLERANCE: People typo "Claude" as cluade, cloude, claud, ckaude. Treat as a mention.

Examples:
- "hey claude what's the weather" -> respond
- "cluade what do u think"        -> respond   (misspelling!)
- "that's cool claude"            -> respond   (engage, don't just react)
- "thanks!"                       -> react:love
- "yo mike you coming tonight?"   -> ignore`,
    messages: [{
      role: 'user',
      content: `${contextBlock}New message from ${sender}: "${message}"\n\nHow should Claude handle this?`
    }],
  });

  // Parse the one-word verdict into an action and optional reaction
  const answer = response.content[0].type === 'text'
    ? response.content[0].text.toLowerCase().trim() : 'ignore';

  if (answer.includes('respond')) return { action: 'respond' };
  if (answer.includes('react'))   return { action: 'react', reaction: /* parse love/like/laugh */ };
  return { action: 'ignore' };
}
```

The inbound webhook handler then becomes a simple gate:

```ts
if (chatContext.isGroupChat) {
  const { action, reaction } = await getGroupChatAction(message, sender, chatId);

  if (action === 'ignore') return;                 // stay silent; most messages land here
  if (action === 'react')  return sendReaction(reaction); // cheap acknowledgment, no generation

  // action === 'respond': only now do we run the full agent
}
const reply = await chat(chatId, message, /* images, audio, context */);
```

### Why the gate works

This pattern works because it gives each model a smaller job.

**Separation of concerns reduces variance.** A narrow classifier with a fixed three-way output and concrete examples is more consistent than a general model making the same judgment while generating a reply. The behavior becomes an explicit, testable decision boundary.

**It is a routing cascade.** A cheap model handles the high-volume case and escalates only when needed. In a busy group, most messages are `ignore`, so the system avoids most frontier-model calls.

**The gate is independently tunable.** If the agent should be chattier, bias the classifier toward `respond`. If it is too noisy, tighten the criteria. You can change turn-taking behavior without editing the main agent prompt or tools. You can also unit-test the classifier against labeled messages, which is much harder to do with an open-ended generation prompt.

**It stops reaction loops early.** Anti-reaction-loop behavior belongs in the gate, before generation starts. The classifier can see recent reactions and choose `respond` or `ignore` instead of continuing the loop.

### Add sender attribution

Group consistency also depends on knowing who said what. In a 1:1 thread, "the user" is clear. In a group, the model needs names or handles.

The same repo prefixes each stored user message with the sender's handle before formatting history for the model:

```ts
function formatHistoryForClaude(messages, isGroupChat) {
  return messages.map(msg => {
    let content = msg.content;
    // In group chats, prefix user messages with who sent them
    if (isGroupChat && msg.role === 'user' && msg.handle) {
      content = `[${msg.handle}]: ${content}`;
    }
    return { role: msg.role, content };
  });
}
```

The system prompt also needs group-specific guidance: address people by name, keep replies shorter because groups move quickly, react less often because reactions can feel spammy, and remember that everyone can see the response.

The classifier decides whether to participate. Attribution helps the main agent participate competently.

## Production shape

A production Linq group-chat agent usually follows this flow:

1. **Inbound webhook** receives a new message and branches on `isGroupChat`.
2. **Gate** runs the Haiku classifier and returns `respond`, `react`, or `ignore`. Most messages stop here.
3. **Generate** runs the Sonnet agent only for `respond`, with sender-attributed history and a group-aware system prompt.
4. **Act** through the API: send the reply, set the group name or icon, add or remove participants, while respecting the 3-member floor and iMessage-only participant management.
5. **Listen** for participant webhooks and keep local state in sync.

The reference implementation is MIT-licensed and runnable: [github.com/linq-team/ai-agent-example](https://github.com/linq-team/ai-agent-example). To try it on a real Linq number across iMessage, RCS, and SMS with about a week of limited usage, request sandbox access at [dashboard.linqapp.com/sandbox-signup](https://dashboard.linqapp.com/sandbox-signup/).

For Ditto-style social agents, the group thread is the core product surface. Treat "should I respond?" as a separate, cheaper decision from "what should I say?" Once those jobs are split, the agent becomes more consistent because the architecture matches the conversation.

### Sources

- Linq docs: [Group Chats guide](https://docs.linqapp.com/guides/chats/group-chats/)
- Linq AI agent example: [repo](https://github.com/linq-team/ai-agent-example) and [`client.ts` classifier](https://github.com/linq-team/ai-agent-example/blob/c4d10a72e7397f1d1d7be8f9a67261bd6f674072/src/claude/client.ts#L745)
- [Ditto](https://ditto.ai/): AI matchmaker over iMessage


Linq's v3 API treats group chats as first-class objects over iMessage and RCS, with display names, icons, participant management, and webhooks for membership changes. This post covers what that makes possible, how to implement it, and the main product problem teams hit when they add an agent to a group: deciding when the agent should speak.

Building AI Agents That Work in Group Chats

Today we're announcing that Linq is an official vendor adapter for [Chat SDK](https://chat-sdk.dev/) — Vercel's open-source TypeScript framework for building bots and agents across every major chat platform.

That means you can now build an AI agent that texts over iMessage, RCS, and SMS — using the same unified API you'd use to build a Slack bot, a Discord bot, or a Teams integration.

## What is Chat SDK?

Chat SDK is a platform-agnostic, event-driven SDK for building chat bots. It abstracts away the differences between Slack, Microsoft Teams, Google Chat, Discord, WhatsApp, and more — so you write your bot logic once and it runs anywhere.

With 1.4M weekly downloads, 2.1K GitHub stars, and 15+ adapters, it's become the standard toolkit for teams building AI-native chat experiences. It's maintained by Vercel and integrates natively with [AI SDK](https://ai-sdk.dev/) for streaming, tool calls, and structured outputs.

## What the Linq adapter adds

With `@linqapp/chat-sdk-adapter`, your Chat SDK bot gains iMessage, RCS, and SMS as delivery channels. Linq's infrastructure handles the carrier layer — your code just sees threads, messages, and reactions like any other Chat SDK adapter.

A few things worth calling out:

**Native iMessage tapbacks.** Tapbacks (like, love, laugh, emphasize, question) map to normalized Chat SDK reaction events, so your `bot.onReaction()` handlers work exactly as they would on Slack.

**Rich media support.** Inbound attachments (images, audio, files) arrive as Chat SDK attachment objects. Outbound files under 10MB are sent by URL reference; larger files up to 100MB are pre-uploaded automatically.

**HMAC-verified webhooks with replay protection.** Every inbound webhook is verified with HMAC-SHA256 and a replay-window check before dispatch. Invalid or stale signatures return 401.

**Stable thread IDs.** Every Linq chat maps to a stable `linq:{chatId}` thread ID across webhook events and API calls, so conversations don't fragment.

## How it works

Install the adapter alongside Chat SDK:

```sh
npm install @linqapp/chat-sdk-adapter chat
```

Wire it up in your bot:

```ts
import { Chat } from "chat";
import { createLinqAdapter } from "@linqapp/chat-sdk-adapter";

const bot = new Chat({
  userName: "mybot",
  adapters: {
    linq: createLinqAdapter({
      apiKey: process.env.LINQ_API_KEY,
      signingSecret: process.env.LINQ_WEBHOOK_SECRET,
    }),
  },
});

bot.onDirectMessage(async (thread, message) => {
  await thread.subscribe();
  await thread.post(`you said: ${message.text}`);
});
```

Then add a webhook route (Next.js example):

```ts
import { after } from "next/server";
import { bot } from "@/lib/bot";

export const runtime = "nodejs";

export async function POST(request: Request) {
  return bot.webhooks.linq(request, {
    waitUntil: (task) => after(() => task),
  });
}
```

Point a Linq webhook at your route and you're live — see the [quickstart guide](https://docs.linqapp.com/guides/integrations/chat-sdk/) for full setup instructions. For local dev, the [Linq CLI](https://www.npmjs.com/package/@linqapp/cli) provisions a sandbox number instantly:

```sh
linq signup
```

## Running a bot across iMessage, WhatsApp, and Telegram — from one codebase

Because Chat SDK is platform-agnostic, adding Linq as an adapter means your existing multi-platform bot logic just works. The [example app in our repo](https://github.com/linq-team/linq-chat-sdk/tree/main/apps/api) shows a single AI agent running across Linq, Telegram, and WhatsApp from one set of handlers — no branching, no per-platform glue.

## A community effort

This integration wouldn't have shipped as fast without [Fardeem Munir](https://x.com/FardeemM), a developer in the Linq community who reached out on Twitter and volunteered his time to help build it. Open source at its best — thanks, Fardeem.

## Get started

- **npm:** [`@linqapp/chat-sdk-adapter`](https://www.npmjs.com/package/@linqapp/chat-sdk-adapter) (Apache-2.0)
- **Docs:** [chat-sdk.dev/adapters/vendor-official/linq](https://chat-sdk.dev/adapters/vendor-official/linq)
- **Source:** [github.com/linq-team/linq-chat-sdk](https://github.com/linq-team/linq-chat-sdk)


Today we're announcing that Linq is an official vendor adapter for Chat SDK, Vercel's open-source TypeScript framework for building bots and agents across every major chat platform.

Linq is now a vendor-official adapter for Vercel's Chat SDK

By betting on iMessage as the channel and Linq as the infrastructure, Tomo built a deeply personal AI product for young people and scaled it from a single phone line to hundreds of thousands of messages through organic growth alone.

Tomo is a personalized AI that lives inside iMessage. It understands users' goals, affirms them, and helps them find ways to achieve those goals. The name means "friend" in Japanese, and there's a friendliness to the product that's core to why it works. Most of Tomo's users are between 15 and 24 years old, and if you try using it, the experience is, as the founders put it, "aggressively Gen Z coded."

Behind that experience is a messaging infrastructure challenge that required the right partner. With Linq, Tomo found a provider that matched their standards on reliability and security, and then kept pace as organic growth pushed their volume from a single phone line to hundreds of thousands of messages.

## From Retool to Tomo

Justin and Raymond, Tomo's co-founders, met while working together at Retool in San Francisco. About a couple of years ago, they left to start separate companies. Justin wanted to build something fun enough for a lot of people to use. Raymond wanted to build something practical with wide-scale impact on real people.

They spent about a year and a half exploring different areas before reuniting around a shared conviction: they wanted to build consumer AI products together.

> "My goal has always been to build for impact and actually deliver value to people. I think what's exciting about Tomo is just seeing that in real time." — Raymond, Co-founder

The result was Tomo: an AI that understands the user's goals, why they care about those goals, and helps them take action. It lives entirely inside iMessage, meeting young users in the app they already use every day.

![The Tomo team](https://res.cloudinary.com/linq/image/upload/v1772835185/website/Customer%20Story/Tomo/Frame_1597881371_kixvg0.png)

## Betting on iMessage

The decision to build on iMessage was straightforward. Tomo's target audience, 15-to-24-year-olds, lives inside the app. People chat a hundred times a day in a space where ten close friends and family members are already texting. For this demographic, anything other than a blue bubble feels like spam.

> "It doesn't take a rocket scientist to know that iMessage is so overpowered. It's almost so overpowered that it's difficult, because you can have a product that isn't really working, but you might think it's working just because iMessage is just so good." — Justin, Co-founder

That power cut both ways. iMessage distribution was a massive advantage, but it also meant they needed infrastructure they could trust completely. The channel was too important to get wrong.

## From building it themselves to finding Linq

Tomo's engineering team was confident. They had phones from other projects, strong technical chops, and the conviction that they could build iMessage infrastructure in-house. They got something working quickly. But it didn't last.

They evaluated providers across multiple companies. The conclusion was clear: the folks at Linq were the best people for the job. The evaluation criteria came down to security, latency, reliability, and price. But above all, Tomo optimized for reliability.

> "You can build a lot of trust for users over 2,000 messages, but it only takes two or three message failures, or even just one, to break that trust."

## When users start caring about privacy, you're winning

Tomo's users share deeply personal information through the product. The things they use Tomo for — their goals, their struggles, their daily lives — are hyper personal. That creates a real obligation around data security, and it makes compliance like SOC 2 matter in practice, not just on paper.

What surprised the team was an emerging signal they didn't expect. As users went deeper into the product, they started asking about data privacy. Not because something went wrong, but because they'd shared so much that the question became personal.

![Tomo on iMessage](https://res.cloudinary.com/linq/image/upload/v1773084933/website/Customer%20Story/Tomo/Tomo_phone_esv06s.jpg)

## From a single phone line to hundreds of thousands of messages

Tomo launched with a single phone line. The first users were the founders themselves, testing with friends, watching hundreds of messages flow through each day, and asking the fundamental question: does this thing have legs?

It did. When the team started promoting on TikTok and Instagram Reels, where their users actually live, demand took off. Through it all, the Linq team kept pace. Five months in, they went from hundreds of messages a day to hundreds of thousands.

## Engagement and retention that finally work

Justin and Raymond have built many consumer products before. But Tomo is the first time they've seen engagement and retention levels where things are clearly starting to work.

The team is now focused on making Tomo more helpful and fun to use with friends. One example: group chats — currently a hidden feature that only the most curious users have discovered, but one the team sees as a natural extension of the product.

## What's next

Tomo's story is still early. The team sees a massive opportunity to scale the product's impact across millions of people, and they're hiring across growth, ops, and engineering to get there. The infrastructure that Linq provides — reliable, secure, and able to scale on demand — is what lets them focus on the product instead of the plumbing.

> "The folks at Linq have always been super gracious and helpful and super responsive. That's been the case whenever we've needed to grow." — Justin, Co-founder, Tomo

How Tomo built a deeply personal AI for young people on iMessage and scaled it from a single phone line to hundreds of thousands of messages on Linq infrastructure — through organic growth alone.

Tomo: How a Personalized AI for Accountability Scaled to Millions of Messages

By treating iMessage as their primary UI and choosing Linq for security, zero data retention, and on-demand scalability, the team behind Poke built a product that scaled entirely through word of mouth — without ever worrying about infrastructure.

The Interaction Company of California builds Poke, a consumer product that treats iMessage as its primary interface. Users don't download an app. They chat. What started as a tool for managing email inside iMessage has evolved into something much broader: a conversational AI that people use for school, daily planning, and personal support.

Founded by Felix and Marvin, two German immigrants who moved to the Bay Area to start a company, the team knew from the beginning that iMessage was the channel. The question was who to trust with the infrastructure that would make it work.

> "We are treating iMessage and SMS as our first-party UI for interacting with our product. That's a space that not very many other companies work in." — Felix, Co-founder

With Linq, the team found the infrastructure partner that made that bet possible and kept pace as organic growth pushed their messaging volume through multiple orders of magnitude.

## Building a product thesis around iMessage

The original idea was straightforward: build something that triggers on every email notification, summarizes the important ones, and lets users act on them without opening an email client. But the team quickly realized people didn't want another email interface. They wanted to interact with email inside the messaging app they already used a hundred times a day.

Samyok, a Member of Technical Staff at the company, joined after interning at Robinhood and Jane Street. He'd been trying to figure out what to do after his last semester when he saw Poke's product thesis in action.

> "When I saw this opportunity, I saw that this product thesis actually works. I decided to join and take a bet. And so far it's paid off really well." — Samyok, Member of Technical Staff

As adoption grew, the team discovered that email was just a fraction of what people used Poke for. Users connected all sorts of services. They used it for school. They used it to chat when they had problems. The product had taken on a life of its own.

![Inside Poke](https://res.cloudinary.com/linq/image/upload/v1772820868/website/Customer%20Story/Poke/CleanShot_2025-09-22_at_09.28.23_1_dkabty.png)

## A waitlist that felt like the product

When it came time to launch, the team faced a constraint: high inference costs meant they had to restrict access. But they didn't want a simple waitlist. Instead, they built something that lived inside the same channel as the product itself.

Users chatted with Poke's bot in iMessage, tried to convince it to give them access, and simultaneously haggled for a good price. The waitlist wasn't a gate. It was a preview of the entire product experience.

## Finding a provider that checked every box

Treating iMessage as a primary UI meant the messaging provider wasn't just infrastructure. It was the product. The team's evaluation criteria reflected that. Functionality came first, then security, then price. They needed SOC 2 compliance, zero data retention, and a provider they could trust.

They searched extensively. Other providers surfaced, but none met the full requirements. Some lacked SOC 2. Others couldn't support zero data retention. Some were significantly more expensive.

> "We did a ton of searching, and we only found Linq to be able to fit all three of these criteria."

The stakes were made viscerally clear before the team even found Linq. While using a previous messaging provider, Poke's messages were flagged as spam. The provider blocked all of Poke's messages for every user, on the day the company closed its fundraise. The experience underscored why the right provider wasn't optional. It was existential.

## Going live with Linq, and building together

Implementation was fast. The team added Linq as a provider with minimal lift, and the first phone line was up and running quickly. But what made the relationship distinctive was what came after onboarding.

Linq built zero data retention specifically for the team, and maintained a tight feedback loop, shipping features in direct response to requests. When someone casually mentioned a Find My location feature, Linq had it done within a week.

![Poke product in action](https://res.cloudinary.com/linq/image/upload/v1772836605/website/Customer%20Story/Poke/Poke_phone_zgsv4m.jpg)

## Scaling through word of mouth, without worrying about infrastructure

The team started in April with a single phone line and a small test group. Growth came in waves: first one line, then around twenty, then hundreds right before launch. Every expansion was driven by organic demand.

Within days of joining the Linq platform, the team was processing ten thousand messages in a single day. From their perspective, the experience was seamless. "It feels like a cloud provider," they say. "We can request a large number of numbers, and you guys just accommodate everything and get it done within a couple of days."

## Launch night

For Felix, the most memorable moment of the past year was launch night. The team pulled an all-nighter. It was hectic. And then the next day, the numbers spiked alongside a wave of positive user feedback that the team says they'll never be able to recreate.

## Infrastructure that lets a team focus on what matters

The team has scaled through multiple orders of magnitude since joining Linq. Instead of planning around infrastructure constraints, the team focuses on product and growth: expanding use cases beyond email and building new interaction models.

> "It feels like a cloud provider. Every time we put in a new order for more capacity, Linq just scales with us. I think there are a lot of other providers on all parts of our infrastructure that would not be able to keep up." — Felix, Co-founder, The Interaction Company of California

How The Interaction Company of California scaled iMessage-based AI with Linq — zero data retention, SOC 2 compliance, and on-demand scalability that kept pace with viral, word-of-mouth growth.

Your agent can buy things now: introducing Agentcard on Linq

Latest Posts

Your agent can buy things now: introducing Agentcard on Linq

The Best Texting API for AI Agents in 2026: A Buyer's Guide

Linq Agent Pay now supports Natural

Are We the Best iMessage API? Here's Why Lindy Chose Linq

Message status webhooks: sent, delivered, failed

iMessage for Agents: How to Integrate iMessage in 5 Easy Steps

Introducing Agent Pay: unlocking commerce for iMessage agents

Now available: Dashboard Single Sign-On

How Lindy shipped an AI assistant into iMessage

Introducing ephemeral messaging: content deletion enforced by Linq

Putting your iMessage agent in the Dynamic Island

Just hit send: Introducing managed load balancing

Supercharge Your Agents With iMessage Apps

Building AI Agents That Work in Group Chats

Linq is now a vendor-official adapter for Vercel's Chat SDK

Tomo: How a Personalized AI for Accountability Scaled to Millions of Messages

How Poke Scaled Messaging

Linq Blog

Your agent can buy things now: introducing Agentcard on Linq

Latest Posts

Your agent can buy things now: introducing Agentcard on Linq

The Best Texting API for AI Agents in 2026: A Buyer's Guide

Linq Agent Pay now supports Natural

Are We the Best iMessage API? Here's Why Lindy Chose Linq

Message status webhooks: sent, delivered, failed

iMessage for Agents: How to Integrate iMessage in 5 Easy Steps

Introducing Agent Pay: unlocking commerce for iMessage agents

Now available: Dashboard Single Sign-On

How Lindy shipped an AI assistant into iMessage

Introducing ephemeral messaging: content deletion enforced by Linq

Putting your iMessage agent in the Dynamic Island

Just hit send: Introducing managed load balancing

Supercharge Your Agents With iMessage Apps

Building AI Agents That Work in Group Chats

Linq is now a vendor-official adapter for Vercel's Chat SDK

Tomo: How a Personalized AI for Accountability Scaled to Millions of Messages

How Poke Scaled Messaging