Powering link previews, metadata extraction, screenshots, Markdown conversion, embeds, and URL intelligence workflows at scale.
You do not choose a resolution strategy. Send the URL and the API works down three tiers until it has something embeddable.
Pass the target as ?url=https://example.com or as a path-encoded segment. Add maxwidth and maxheight when your layout needs a specific size.
Known providers are passed straight through. Pages that advertise their own oEmbed endpoint are discovered and fetched. Everything else gets a hosted embed card built from its metadata.
One field renders every tier. The source field tells you which path produced the embed, so you can label it, cache it, or style it differently.
Every successful response carries a source field naming the tier that answered, so you can label embeds in your UI or debug a surprising result without guessing.
source: nativeThe URL matches a known oEmbed provider such as YouTube, Vimeo, TikTok, or Spotify. The provider response is passed through untouched, including its own iframe HTML.
source: discoveryThe page advertises an oEmbed endpoint through a discovery link tag. We fetch that endpoint directly, forwarding your sizing hints, and return what it gives us.
source: og_frameNo native embed exists. We build a hosted card from the page Open Graph metadata, so a plain article, product, or documentation URL still returns something embeddable.
The response is oEmbed-shaped, so existing consumers keep working, with a few additions that make the fallback tier usable.
A single html field you can drop into your page, whether it came from a native provider or our hosted card.
Standard type, width, height, provider_name, and html fields, so existing oEmbed consumers work unchanged.
A source field of native, discovery, or og_frame on every response so you always know which tier answered.
maxwidth and maxheight are forwarded to native providers and applied to hosted card dimensions.
Thumbnails and preview images from the target page, used in hosted cards and available to your own UI.
Page metadata alongside the embed so you can render context, alt text, or accessible labels.
Hosted cards carry an embed_id you can store, refresh, or invalidate through the frame management API.
Failures return a code, message, and stage instead of an opaque string, so retries can be targeted.
Both URL forms work on v1.1 and v3.0. Full parameter reference, proxy options, and error codes live in the API docs.
The pattern is the same wherever URLs arrive from somewhere you do not control: you cannot know in advance whether a native embed exists.
Render a real embed for whatever URL someone pastes into a comment, post, or message, without maintaining a provider allowlist.
Give editors one paste-a-URL flow that produces consistent embeds across video, social, articles, and internal pages.
Turn linked resources into visual cards so a list of URLs becomes scannable instead of a wall of blue text.
Let an agent cite a source and render it as a card, using one call that never needs per-domain handling.
Worth knowing before you build: branding only ever applies to hosted fallback cards, never to native provider embeds.
The first two are the same endpoint described for different audiences. The third is for when you want the data, not the HTML.
The same engine, documented against the oEmbed 1.0 spec and its provider registry.
You are replacing an existing oEmbed integration and need the spec-level details: provider coverage, discovery behavior, and parameter compatibility.
Metadata for building your own preview card: title, description, image, and domain.
You want to render the card yourself in your own components rather than embedding our HTML.
No provider registrations, no per-platform API keys, no OAuth dances. Add your app_id and send a URL.
Your rendering code reads the same fields whichever tier answered, so there is no branching to maintain.
The dashboard playground runs real requests against real URLs, including the fallback tier, with a live preview.
Sizing, theming, proxying, and rendering options are all in the API reference rather than buried in support threads.
Requests to internal and blocked hosts are rejected before fetch, which matters when your users supply the URLs.
Pair embeds with metadata, screenshots, Markdown, and extraction when one call is not enough context.