Video API

Get structured data from Pinterest video pins by URL: metadata, frames sampled at any rate in jpg, png, or webp, and the on-screen text burned into them. Pinterest video pins are typically silent or music-only, and Pinterest exposes no caption or transcript surface for them — FrameFetch says so up front instead of returning an empty or fabricated field.

Read the docs Pricing

A Pinterest URL doesn't tell you what's behind it: pins can be a single static image, a multi-image carousel, or an actual video — and the pinterest.com/pin/<id> shape looks identical either way. FrameFetch doesn't pre-screen this for you before charging: send a pin URL, and if it's a video pin, metadata, frames, and text_overlay all work normally. If it turns out to be an image or carousel pin, there's no video stream to sample — frames and text_overlay fail to extract (no charge for the failed field), while metadata still returns whatever Pinterest exposes for that pin. If you're processing pins in bulk and want to skip non-video ones before spending a call, check the pin in a browser first — there's no cheaper pre-check FrameFetch can offer that Pinterest itself doesn't already gate.

For a video pin, FrameFetch returns the same metadata/insights shape every platform gets: title, uploader, duration, upload date, and a thumbnail; views, likes, and comment count where the platform exposes them. Individual fields come back null rather than guessed when Pinterest itself doesn't publish them for a given pin — FrameFetch doesn't backfill missing numbers.

This table matches the live capability matrix at GET /v1/platforms — check it programmatically before requesting a field, rather than hardcoding assumptions.

The top-level ask question-answering param (see docs) still works on Pinterest despite the missing transcript: with no transcript to read, it falls back to answering from the pin's sampled frames instead of declining — ask.based_on reads ["frames"] and ask.confidence is capped below "high" for that weaker evidence, at the same flat price.

curl -X POST https://framefetch.net/v1/extract \
  -H "Authorization: Bearer <your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.pinterest.com/pin/PIN_ID/",
    "fields": ["metadata", "frames"],
    "frames": { "mode": "fps", "fps": 1, "width": 480 }
  }'

Get a key with POST /v1/keys (free credit). Full reference in the docs. Agents can pay per call with x402 (USDC) — no account.

Add "text_overlay" alongside "frames" to run OCR on each extracted frame — useful for pins that are effectively recipe cards, infographics, or text-over-video content, where the words on screen carry more information than the audio track.

curl -X POST https://framefetch.net/v1/extract \
  -H "Authorization: Bearer <your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.pinterest.com/pin/PIN_ID/",
    "fields": ["frames", "text_overlay"],
    "frames": { "mode": "every_n", "n": 30, "width": 480 }
  }'

Some competing "downloader" tools imply universal transcription by not mentioning the gap at all — they'll happily accept a Pinterest URL and either return nothing for the transcript field or silently fail. FrameFetch's capability matrix marks Pinterest's transcript as false: requesting it is simply omitted from the response with a warning, and it is never billed. There's no roadmap promise here either — Pinterest video pins are typically silent or set to background music, so a speech transcript wouldn't be meaningful even if Pinterest exposed better audio access. If your workflow needs Pinterest's on-screen text, text_overlay is the field that actually carries information for this platform.

FrameFetch ships an MCP server at POST https://framefetch.net/mcp with the tools framefetch_extract and framefetch_platform_capabilities — the latter is the one to call first for Pinterest, so your agent checks transcript: false before it ever asks for one. See the MCP setup guide for a working Claude Desktop / Cursor config.