|

Linq’s iMessage Apps Bring Payments, Tickets, Flights, and Games Into the iMessage Bubble Through the imessage_app Part

Linq builders can now construct iMessage Apps. These are interactive mini-apps that run inside a iMessages dialog.

A consumer can store, play a recreation, e-book a flight, or pay. None of it requires leaving the iMessage thread. There isn’t any deep hyperlink to an exterior browser. There isn’t any ‘faucet right here to complete in the app.’

Previously, an agent’s most important API possibility was to ship a hyperlink. The consumer then needed to comply with it someplace else. iMessage Apps take away that handoff.

TL;DR

  • Linq’s new imessage_app half renders tappable, interactive playing cards instantly inside an iMessage thread.
  • One card handles full workflows: video games, funds, tickets, flights, music, and relationship.
  • Cards replace in place by way of /messages/{id}/replace, so state adjustments redraw the similar bubble.
  • An interactive flag toggles the dwell expertise versus a static caption-only structure card.
  • It’s iMessage-only with no SMS/RCS fallback, and wealthy rendering wants your app put in.

iMessage Apps

An iMessage App is a tappable card that opens an interactive expertise in place. The card turns into your app inside the bubble.

Technically, it’s a new message half with kind: "imessage_app". This replaces the textual content, media, and hyperlink components you already use. An put in Messages extension attracts the wealthy content material from a url you present.

Linq is the messaging-infrastructure startup behind the API. Its platform lets AI brokers message customers over iMessage, RCS, and SMS.

How It Works

Just a few particulars resolve whether or not your first card renders accurately.

The app id is the rendering key: The app object carries team_id and bundle_id. Those fields inform Messages which extension renders the card. team_id is the app’s 10-character uppercase identifier. You often go your personal app’s id.

There is one widespread failure mode right here. An unrecognized id silently renders as plain textual content. If team_id and bundle_id don’t match an put in extension, the card falls again to your caption. No error is thrown.

You management captions; the app controls the picture: The structure object holds the textual content drawn on the card. There isn’t any picture subject. The picture, icon, and interactive UI come out of your extension.

structure subject Position
caption top-left, daring main label
subcaption left, under caption
trailing_caption top-right
trailing_subcaption proper, under trailing_caption

At least one subject should be set. Otherwise the card renders as an empty bubble. Messages treats the url as opaque, so altering the url adjustments what the card exhibits.

An interactive flag controls dwell versus static. It defaults to true. With true, recipients who’ve your app see the dwell card. Set it to false to at all times present the static structure card as an alternative.

Install state and the flag collectively resolve the outcome. Three outcomes are potential:

  • Has your app, interactive: true → the extension renders the wealthy card out of your url.
  • Has your app, interactive: false → the recipient sees the static structure card.
  • No app → the recipient sees your structure captions. Set app_store_id so as to add a Get the app affordance.

Implementation: Sending and Updating a Card

Send a card with Create Chat, or put up it into an current chat with Send Message.

curl -X POST https://api.linqapp.com/api/associate/v3/chats 
  -H "Authorization: Bearer $LINQ_API_KEY" 
  -H "Content-Type: software/json" 
  -d '{
    "from": "+12052535597",
    "to": ["+12052532136"],
    "message": {
      "components": [
        {
          "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"
          }
        }
      ]
    }
  }'

Updates are the attention-grabbing primitive. A delivered card might be changed in place by referencing the authentic message. This is how a recreation transfer redraws a board.

curl -X POST https://api.linqapp.com/api/associate/v3/messages/{messageId}/replace 
  -H "Authorization: Bearer $LINQ_API_KEY" 
  -H "Content-Type: software/json" 
  -d '{
    "url": "https://app.instance.com/card?recreation=7f3a&transfer=2",
    "fallback_text": "Score replace",
    "structure": { "caption": "Score: 2 - 1" }
  }'

Just a few guidelines govern updates. Only url, fallback_text, interactive, and structure can change. The app id stays fastened for the card’s life. The card should already be delivered.

You can replace solely an imessage_app card you despatched. Inbound playing cards can’t be up to date, and the name returns 400. A 409 means the card shouldn’t be delivered but. Retry after the message.delivered webhook.

Each replace is delivered as a brand new message with its personal ID. The interactive flag shouldn’t be inherited, so resend it every time. To replace once more, reference the new message ID.

You may obtain playing cards. Inbound messages embrace an imessage_app half in the message.acquired webhook.

What You Can Build

Linq frames these as examples, not a hard and fast menu. Try each your self in the interactive demo under (created by Marktechpost).

  • Games: Send a transfer and redraw the board. A dwell match turns into a sequence of updates to 1 bubble.
  • Payments: Send a checkout or request-to-pay as a card. The recipient completes it with no redirect.
  • Tickets: A card can transfer from “Going / Not going” to a confirmed ticket in place.
  • Flight reserving: Surface a fare, let the consumer choose a seat, then replace the card to a boarding go.
  • Music. Drop a monitor and let folks play it inline. The card is a participant, not a hyperlink.
  • Dating: Let customers swipe profiles and discover matches the place they already discuss.



iMessage Apps vs Other Message Parts

The imessage_app half trades attain for interactivity. This desk exhibits the tradeoff:

Capability imessage_app textual content media hyperlink (wealthy hyperlink)
Interactive in the bubble Yes No No No
Updates in place Yes, by way of /replace No No No
Drawn by Your Messages extension Messages Messages Messages
Visible with out your app Captions solely Always Always Always
Falls again to SMS or RCS No Yes Yes Yes
Combine with different components No, should be the solely half Yes Yes Yes

If you want a picture everybody can see, use media or a wealthy hyperlink. That is a distinct instrument for a distinct job.

Strengths and Weaknesses

Strengths

  • In-place updates flip one card right into a stateful, multi-step workflow.
  • The interactive workflow runs in the thread, with no browser redirect.
  • The API floor is small: ship, replace, obtain, plus webhooks.
  • Captions give a swish, predictable fallback for recipients with out the app.

Weaknesses

  • iMessage solely, with no SMS or RCS fallback, limits world attain.
  • Rich rendering depends upon the recipient putting in your Messages extension.
  • The team_id and bundle_id failure mode is silent, not loud.
  • It builds on Apple’s platform, which carries the typical platform danger.


Check out the Technical details. Also, be happy to comply with us on Twitter and don’t overlook to affix our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.

Need to associate with us for selling your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar and many others.? Connect with us

The put up Linq’s iMessage Apps Bring Payments, Tickets, Flights, and Games Into the iMessage Bubble Through the imessage_app Part appeared first on MarkTechPost.

Similar Posts