Rich Link Previews
Send URLs that render as inline previews with a title, description, and image.
A link part renders a URL as a rich inline card — title, description, and preview image — instead of a bare blue-link string. It’s the same affordance you see when you paste a URL into Messages manually.
Rich link previews are available on iMessage and RCS. On SMS, link parts fall back to a plain text URL.
Sending a link part
Section titled “Sending a link part”curl -X POST https://api.linqapp.com/api/partner/v3/chats/{chatId}/messages \ -H "Authorization: Bearer $LINQ_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "message": { "parts": [ { "type": "link", "value": "https://linqapp.com" } ] } }'await client.chats.messages.send({chatId}, { message: { parts: [ { type: "link", value: "https://linqapp.com", }, ], },});client.chats.messages.send( {chat_id}, message={ "parts": [ { "type": "link", "value": "https://linqapp.com", }, ], },)client.Chats.Messages.Send(context.TODO(), {chatId}, linq.ChatMessageSendParams{ Message: linq.F(map[string]any{ Parts: linq.F([]any{ map[string]any{ Type: linq.F("link"), Value: linq.F("https://linqapp.com"), }, }), }),})Constraints
Section titled “Constraints”| Rule | Value |
|---|---|
| Must be the only part in the message | A link part cannot be mixed with text or media parts |
| URL max length | 2,048 characters |
| URL protocol | HTTPS required for preview generation |
| Fallback on SMS | Bare text URL |
Violating the “only part” rule returns error 1004 (Invalid message content).
How previews are generated
Section titled “How previews are generated”The preview (title, description, hero image) is fetched from the target page’s standard metadata:
- Open Graph tags (
og:title,og:description,og:image) - Twitter Card tags as a fallback
- Standard HTML
<title>and first suitable<img>if neither is present
For the best-looking preview on your own domain, publish proper Open Graph tags on every page you send. Pages behind auth, intranet URLs, and pages that block the Linq preview fetcher will render as plain-link fallbacks.
When to use link parts vs. text + URL
Section titled “When to use link parts vs. text + URL”| Goal | Use |
|---|---|
| Rich card with title and image | Link part (this guide) |
| Short message that happens to contain a URL | Text part — iMessage auto-previews the URL inline |
| Multiple URLs in one message | Multiple messages, one link part each (link parts can’t be mixed) |
Best practices
Section titled “Best practices”- Prefer short links. Use a link shortener or a branded short link and store parameters server-side, so the URL you send is compact and self-contained (
https://link.example.app/aB3xYz) rather than a fully expanded query string. - Keep query strings minimal. Move campaign, attribution, and deep-link data behind the short link instead of inlining it. Avoid encoded reserved characters (
{ } " :) in the visible URL. - One link, at the end. Put a single URL on its own line at the end of the message body for the most reliable preview.
- Make the link self-sufficient. Don’t rely on the preview to carry the full URL — the shortened target should resolve to the correct destination on its own.
# Good — compact, self-contained, parameters stored server-sidehttps://link.example.app/aB3xYz
# Bad — long query string, encoded reserved characters, attribution inlinedhttps://example.com/promo?utm_source=sms&utm_campaign=summer&ref=%7Bpartner%7D&deep_link=%22app%3A%2F%2Fhome%22Related
Section titled “Related”- Sending Messages — message parts
- Protocol Selection — which services render rich previews
- Error 1004 — Invalid message content
- API Reference: Send Message