A link preview needs two things: a picture of the page and enough text to describe it. Most implementations fetch the HTML and parse Open Graph tags, which fails on every site that renders client-side or ships no tags at all.
Rendering gives you both.
# the picture
curl -o preview.png \
"https://api.screenshotline.com/take?url=${URL}&viewport_width=1200&viewport_height=630&cache=true&cache_ttl=86400" \
-H "X-Access-Key: $KEY"
# the text, as Markdown
curl "https://api.screenshotline.com/extract?url=${URL}&max_chars=600&response=json" \
-H "X-Access-Key: $KEY"
The JSON response carries the page title, the final URL and the Markdown, so the card can show the real title rather than a guess.
Why this beats parsing HTML
A plain fetch of a modern web app returns a shell. One dashboard I test against returns 121 characters of visible text, roughly "this app needs JavaScript". Rendered first, the same URL returns the page.
Consent banners are removed before either output, so the preview is the page rather than a cookie wall, and lazy images have loaded by the time the frame is taken.
Keep it safe
You are fetching URLs that strangers typed, which is server-side request forgery with extra steps. The API refuses private and reserved addresses, re-checks after every redirect hop, and refuses literal private IPs for every subresource a page pulls. On your side, keep your own timeout and a size limit.
Keep it cheap
Turn the cache on, with a TTL that matches how often a shared link changes. Cache hits are never billed and return in milliseconds, which is what a chat UI needs.
For a high-volume feed, render once when the link is first posted and store the image yourself. The API is the renderer, not your CDN.