Link Preview API: Safe Link Previews Without Building a Scraper

Generate link previews with one API call — title, description, image, plus a built-in malicious-link check. No scraper to maintain, no SSRF risk, serverless-ready.

Nikolas Dimitroulakis

Last updated on July 04, 2026

title: "Link Preview API: Safe Link Previews Without Building a Scraper" meta_description: "Generate link previews with one API call — title, description, image, plus a built-in malicious-link check. No scraper to maintain, no SSRF risk, serverless-ready." suggested_category: Utility APIs suggested_slug: link-previews-common-challenges-apyhub-api

Link Preview API: Safe Link Previews Without Building a Scraper

Introduction

Most teams that add link previews to an app start the same way: a fetch call to the pasted URL, an HTML parser like Cheerio or BeautifulSoup to pull the Open Graph tags, maybe an open-source library such as link-preview-js to wrap it up — and, when JavaScript-rendered pages break that approach, a headless browser to render the page first. Each of these works in a demo. Each of them falls short in production, where the URLs come from strangers, the metadata is inconsistent, half the web blocks unknown scrapers, and some of the links are actively hostile.

ApyHub's Link Preview API exists for exactly this gap: one POST request that fetches the URL on ApyHub's infrastructure, extracts the metadata, and tells you whether the link has been reported as malicious — so your own servers never touch the pasted URL at all.

Common Challenges in Building Link Previews

1. Your server fetching URLs that strangers typed

The core mechanic of a DIY link preview is uncomfortable when you say it plainly: your backend downloads whatever anyone pastes into a text box. That includes internal addresses — http://169.254.169.254, http://localhost:6379, the private IPs of your own infrastructure — which is how a preview feature becomes a server-side request forgery (SSRF) finding in your next security audit. Defending against this properly means IP allow-listing, DNS rebinding protection, and redirect validation, all maintained forever.

ApyHub's API Solution: the fetch happens on ApyHub's infrastructure, not yours. Your server sends the URL to the API and receives metadata back; it never opens a connection to the pasted address. The request also accepts a secure_mode flag, and because the integration is a single outbound HTTPS call, it runs cleanly from a serverless function or edge worker with nothing to isolate.

2. Metadata that's different on every site

Open Graph tags are a convention, not a guarantee. Some pages use Twitter Card tags instead, some use both with different values, some have malformed HTML that breaks parsers, and some put the useful image in a favicon or an embedded video thumbnail. A hand-rolled parser ends up as a growing pile of special cases.

ApyHub's API Solution: the API extracts the page's title, description, and image, along with the site name, media type, content type, favicons, and associated images and videos where present — normalized into one JSON response regardless of how the page marked itself up. If you specifically want Twitter Card images over Open Graph ones, the images_property_type parameter lets you choose.

3. Sites that block scrapers

Production traffic reveals a problem demos never hit: many sites serve different content — or an outright block page — to requests that don't look like a browser or a known crawler. Your preview feature works for a week, then a major domain starts returning empty metadata.

ApyHub's API Solution: the request accepts a user_agent parameter (for example, google-bot) and an accept_language parameter, so the fetch presents itself in a way target sites respond to. An allow_redirect flag controls whether redirect chains are followed to the final destination — useful when shortened URLs are involved.

4. Malicious links wearing a nice preview

Here's the uncomfortable irony of preview cards: a rendered title, description, and image makes any link look more legitimate — including a phishing link. If your app previews URLs without screening them, the preview card itself becomes the attacker's best asset.

ApyHub's API Solution: every response includes a reported_malicious boolean, indicating whether the URL has been reported as malicious against known threat reports. Your app can render the card when it's false and hide the preview or warn the user when it's true. No screening of this kind is 100% accurate — no link scanner is — but it turns the preview feature from a phishing amplifier into a line of defense.

The request parameters, and when to use them

The API's behavior is tunable per request:

url (required) — the link to preview.
user_agent — present the fetch as a specific agent (e.g. google-bot) for sites that filter unknown clients.
accept_language — request metadata in a specific language where the target site localizes (e.g. en-US).
images_property_type — choose which image tags to prefer, such as Twitter Card (twitter) images over the default.
secure_mode — enable the stricter fetching mode for untrusted input.
allow_redirect — follow redirect chains (shortened links, tracking wrappers) to the final page before extracting metadata.

For most consumer-facing use cases — chat messages, comments, CRM notes — sensible defaults are secure_mode: true and allow_redirect: true, since pasted links are untrusted and frequently shortened.

About ApyHub's Link Preview API

The Link Preview API is a single REST endpoint: you POST a URL, and it returns the page's metadata plus a malicious-link flag. A request looks like this:

1
curl -X POST https://api.apyhub.com/extract/url/preview \
2
  -H "Content-Type: application/json" \
3
  -H "apy-token: YOUR_APY_TOKEN" \
4
  -d '{
5
    "url": "https://example.com/pricing",
6
    "user_agent": "google-bot",
7
    "accept_language": "en-US",
8
    "secure_mode": true,
9
    "allow_redirect": true
10
  }'

And a response carries the fields you render the card from:

1
{
2
  "title": "Example — Simple pricing for teams",
3
  "description": "Start free. Scale when you're ready. No credit card required.",
4
  "image": "https://example.com/og-image.png",
5
  "reported_malicious": false
6
}

Responses also include the site name, media type, content type, and favicon data where the page provides them [VERIFY: exact field names/casing for these additional response fields against the live API reference before publishing]. Malformed URLs return an appropriate error rather than a partial response, so failure handling is a status-code check, not HTML forensics.

Like every endpoint in the ApyHub catalog, the Link Preview API is MCP-ready by default, so agent runtimes can discover and call it without custom glue code, and it's covered by the single catalog-wide subscription — usage is billed in atoms from the same pool as every other API you use.

Try the Link Preview API →

Conclusion

Link previews are a one-afternoon feature with a multi-year tail: fetching strangers' URLs safely, parsing inconsistent metadata, staying ahead of scraper-blocking, and screening for malicious links are each ongoing engineering work in their own right. The Link Preview API collapses all four into one HTTPS call that runs anywhere — and returns a reported_malicious flag so the card you render makes your users safer, not more exposed. Paste a real URL into the API playground and you'll have your first preview card in a few minutes.

Explore the catalog →

FAQ

What is the ApyHub Link Preview API? It's a REST API that takes a URL and returns the page's title, description, image, and related metadata, plus a flag indicating whether the URL has been reported as malicious. You use the response to render a preview card in your app.

Do I need to fetch the webpage myself first? No — that's the point. You send only the URL to the API; ApyHub's infrastructure fetches the page and extracts the metadata. Your servers never connect to the pasted URL.

How does the malicious-link check work? Every response includes a reported_malicious boolean based on whether the URL has been reported as malicious. Render the preview when it's false; hide it or show a warning when it's true. No link screening is 100% accurate, so treat it as a strong signal, not a guarantee.

Why shouldn't I just parse Open Graph tags myself? Parsing is the easy 20%. The hard 80% is fetching untrusted URLs without exposing your infrastructure to SSRF, handling sites that block unknown scrapers, normalizing inconsistent or broken metadata, and screening for malicious links — each of which the API handles in the same call.

What is SSRF and why does it matter for link previews? Server-side request forgery is when an attacker makes your server request an address of their choosing — like your cloud metadata endpoint or an internal service — by pasting it where a URL is accepted. A DIY preview fetcher is a textbook SSRF surface; using the API removes it, because the fetch never runs on your infrastructure.

Can I get Twitter Card images instead of Open Graph images? Yes — set the images_property_type parameter (for example, to twitter) to prefer Twitter Card image tags in the response.

What about shortened or redirecting URLs? Set allow_redirect: true and the API follows the redirect chain to the final destination before extracting metadata, so a bit.ly-style link previews as the real page behind it.

Some sites return empty metadata to my scraper. Does the API handle that? The user_agent parameter lets the fetch present itself as a specific agent (such as google-bot), which resolves most cases where sites filter unknown clients. You can combine it with accept_language for localized pages.

What happens if the URL is malformed or unreachable? The API returns an appropriate error response rather than partial data, so your integration handles failures with a standard status-code check.

Should I cache the responses? Yes. Page metadata rarely changes, so cache responses keyed by URL and you avoid paying for repeat lookups of the same link — a chat room sharing one article shouldn't trigger a fetch per message.

Does it work in a serverless function? Yes — the integration is a single outbound HTTPS request with a JSON body, so it fits in an AWS Lambda, a Cloudflare Worker, or any edge function without special networking.

How do I get started, and is there a free tier? Sign up at apyhub.com, grab your apy-token, and test the endpoint from the API playground on the Link Preview API page. ApyHub's free tier requires no card and includes access to every API in the catalog.

Can AI agents use this API? Yes — every ApyHub endpoint is MCP-ready by default, so agent runtimes like Claude or Cursor can discover and call the Link Preview API without custom tool definitions or wrapper code.

About ApyHub

ApyHub is a curated API catalog and trusted operational layer where developers, teams, and AI agents discover and consume production-ready APIs — 200+ APIs and 1,000+ endpoints covering conversion, validation, extraction, data processing, and more — under a single subscription billed in atoms. Every endpoint ships with machine-readable certification aligned with standards like GDPR, SOC 2, and ISO 27001, and is MCP-ready by default.

Building APIs yourself? You can publish your own API on ApyHub in about ten minutes.