{"slug": "linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage", "title": "Linq’s iMessage Apps Bring Payments, Tickets, Flights, and Games Into the iMessage Bubble Through the imessage_app Part", "summary": "Linq launched iMessage Apps, interactive mini-apps that let users shop, play games, book flights, or pay directly inside an iMessage thread without leaving the conversation. The new imessage_app API part renders tappable cards that update in place, replacing the need for external links or deep links. This enables AI agents to deliver full workflows within iMessage, with rich rendering requiring the recipient's app installed.", "body_md": "Linq developers can now build ** iMessage Apps**. These are interactive mini-apps that run inside a iMessages conversation.\n\nA user can shop, play a game, book a flight, or pay. None of it requires leaving the iMessage thread. There is no deep link to an external browser. There is no ‘tap here to finish in the app.’\n\nPreviously, an agent’s main API option was to send a link. The user then had to follow it somewhere else. iMessage Apps remove that handoff.\n\n**TL;DR**\n\n- Linq’s new\n`imessage_app`\n\npart renders tappable, interactive cards directly inside an iMessage thread. - One card handles full workflows: games, payments, tickets, flights, music, and dating.\n- Cards update in place via\n`/messages/{id}/update`\n\n, so state changes redraw the same bubble. - An\n`interactive`\n\nflag toggles the live experience versus a static caption-only`layout`\n\ncard. - It’s iMessage-only with no SMS/RCS fallback, and rich rendering needs your app installed.\n\n**iMessage Apps**\n\nAn iMessage App is a tappable card that opens an interactive experience in place. The card becomes your app inside the bubble.\n\nTechnically, it is a new message **part** with `type: \"imessage_app\"`\n\n. This replaces the `text`\n\n, `media`\n\n, and `link`\n\nparts you already use. An installed Messages extension draws the rich content from a `url`\n\nyou provide.\n\nLinq is the messaging-infrastructure startup behind the API. Its platform lets AI agents message users over iMessage, RCS, and SMS.\n\n**How It Works**\n\nA few details decide whether your first card renders correctly.\n\n**The app identity is the rendering key**: The `app`\n\nobject carries `team_id`\n\nand `bundle_id`\n\n. Those fields tell Messages which extension renders the card. `team_id`\n\nis the app’s 10-character uppercase identifier. You usually pass your own app’s identity.\n\nThere is one common failure mode here. An unrecognized identity silently renders as plain text. If `team_id`\n\nand `bundle_id`\n\ndo not match an installed extension, the card falls back to your caption. No error is thrown.\n\n**You control captions; the app controls the image**: The `layout`\n\nobject holds the text drawn on the card. There is no image field. The photo, icon, and interactive UI come from your extension.\n\n`layout` field | Position |\n|---|---|\n`caption` | top-left, bold primary label |\n`subcaption` | left, below `caption` |\n`trailing_caption` | top-right |\n`trailing_subcaption` | right, below `trailing_caption` |\n\nAt least one field must be set. Otherwise the card renders as an empty bubble. Messages treats the `url`\n\nas opaque, so changing the `url`\n\nchanges what the card shows.\n\n**An interactive flag controls live versus static.** It defaults to\n\n`true`\n\n. With `true`\n\n, recipients who have your app see the live card. Set it to `false`\n\nto always show the static `layout`\n\ncard instead.**Install state and the flag together decide the result.** Three outcomes are possible:\n\n- Has your app,\n`interactive: true`\n\n→ the extension renders the rich card from your`url`\n\n. - Has your app,\n`interactive: false`\n\n→ the recipient sees the static`layout`\n\ncard. - No app → the recipient sees your\n`layout`\n\ncaptions. Set`app_store_id`\n\nto add a**Get the app** affordance.\n\n**Implementation: Sending and Updating a Card**\n\nSend a card with **Create Chat**, or post it into an existing chat with **Send Message**.\n\n```\ncurl -X POST https://api.linqapp.com/api/partner/v3/chats \\\n  -H \"Authorization: Bearer $LINQ_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"from\": \"+12052535597\",\n    \"to\": [\"+12052532136\"],\n    \"message\": {\n      \"parts\": [\n        {\n          \"type\": \"imessage_app\",\n          \"app\": {\n            \"name\": \"Example App\",\n            \"team_id\": \"A1B2C3D4E5\",\n            \"bundle_id\": \"com.example.app.MessageExtension\"\n          },\n          \"url\": \"https://app.example.com/card?id=abc123\",\n          \"fallback_text\": \"Open in Example App\",\n          \"layout\": {\n            \"caption\": \"Example App\",\n            \"subcaption\": \"You said: hello\"\n          }\n        }\n      ]\n    }\n  }'\n```\n\nUpdates are the interesting primitive. A delivered card can be replaced in place by referencing the original message. This is how a game move redraws a board.\n\n```\ncurl -X POST https://api.linqapp.com/api/partner/v3/messages/{messageId}/update \\\n  -H \"Authorization: Bearer $LINQ_API_KEY\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"url\": \"https://app.example.com/card?game=7f3a&move=2\",\n    \"fallback_text\": \"Score update\",\n    \"layout\": { \"caption\": \"Score: 2 - 1\" }\n  }'\n```\n\nA few rules govern updates. Only `url`\n\n, `fallback_text`\n\n, `interactive`\n\n, and `layout`\n\ncan change. The app identity stays fixed for the card’s life. The card must already be **delivered**.\n\nYou can update only an `imessage_app`\n\ncard you sent. Inbound cards cannot be updated, and the call returns `400`\n\n. A `409`\n\nmeans the card is not delivered yet. Retry after the `message.delivered`\n\nwebhook.\n\nEach update is delivered as a new message with its own ID. The `interactive`\n\nflag is not inherited, so resend it each time. To update again, reference the new message ID.\n\nYou can also receive cards. Inbound messages include an `imessage_app`\n\npart in the `message.received`\n\nwebhook.\n\n**What You Can Build**\n\nLinq frames these as examples, not a fixed menu. Try each one yourself in the interactive demo below (created by Marktechpost).\n\n**Games**: Send a move and redraw the board. A live match becomes a sequence of updates to one bubble.** Payments**: Send a checkout or request-to-pay as a card. The recipient completes it without a redirect.** Tickets**: A card can move from “Going / Not going” to a confirmed ticket in place.** Flight booking**: Surface a fare, let the user pick a seat, then update the card to a boarding pass.** Music.**Drop a track and let people play it inline. The card is a player, not a link.** Dating**: Let users swipe profiles and explore matches where they already talk.\n\n**iMessage Apps vs Other Message Parts**\n\nThe `imessage_app`\n\npart trades reach for interactivity. **This table shows the tradeoff**:\n\n| Capability | `imessage_app` | `text` | `media` | `link` (rich link) |\n|---|---|---|---|---|\n| Interactive in the bubble | Yes | No | No | No |\n| Updates in place | Yes, via `/update` | No | No | No |\n| Drawn by | Your Messages extension | Messages | Messages | Messages |\n| Visible without your app | Captions only | Always | Always | Always |\n| Falls back to SMS or RCS | No | Yes | Yes | Yes |\n| Combine with other parts | No, must be the only part | Yes | Yes | Yes |\n\nIf you need an image everyone can see, use media or a rich link. That is a different tool for a different job.\n\n**Strengths and Weaknesses**\n\n**Strengths**\n\n- In-place updates turn one card into a stateful, multi-step workflow.\n- The interactive workflow runs in the thread, with no browser redirect.\n- The API surface is small: send, update, receive, plus webhooks.\n- Captions give a graceful, predictable fallback for recipients without the app.\n\n**Weaknesses**\n\n- iMessage only, with no SMS or RCS fallback, limits global reach.\n- Rich rendering depends on the recipient installing your Messages extension.\n- The\n`team_id`\n\nand`bundle_id`\n\nfailure mode is silent, not loud. - It builds on Apple’s platform, which carries the usual platform risk.\n\nCheck out the** Technical details**.\n\n**Also, feel free to follow us on**\n\n**and don’t forget to join our**[Twitter](https://x.com/intent/follow?screen_name=marktechpost)\n\n**and Subscribe to**\n\n[150k+ML SubReddit](https://www.reddit.com/r/machinelearningnews/)**. Wait! are you on telegram?**\n\n[our Newsletter](https://www.aidevsignals.com/)\n\n[now you can join us on telegram as well.](https://t.me/machinelearningresearchnews)Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? [Connect with us](https://forms.gle/wbash1wF6efRj8G58)", "url": "https://wpnews.pro/news/linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage", "canonical_source": "https://www.marktechpost.com/2026/06/30/linqs-imessage-apps/", "published_at": "2026-06-30 22:17:56+00:00", "updated_at": "2026-06-30 22:32:09.215674+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products"], "entities": ["Linq", "iMessage", "Apple"], "alternates": {"html": "https://wpnews.pro/news/linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage", "markdown": "https://wpnews.pro/news/linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage.md", "text": "https://wpnews.pro/news/linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage.txt", "jsonld": "https://wpnews.pro/news/linqs-imessage-apps-bring-payments-tickets-flights-and-games-into-the-imessage.jsonld"}}