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.

Introducing Agent Pay: unlocking commerce for iMessage agents

Latest Posts

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

Introducing Agent Pay: unlocking commerce for iMessage agents

Latest Posts

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