Pinterest Unofficial API: Pins, Boards and Search 2026

Pinterest does have an official API — the v5 API — but getting it to actually serve the public read access most people want is the hard part. You apply for app access, you often start in a trial/standard-access state with tight limits, and the API is oriented toward managing your own boards, pins, and ads rather than reading arbitrary public content at scale. Approval is gated, scopes are restricted, and the whole flow is built for a brand managing its presence, not an analyst pulling pins and boards across the platform. This guide covers the Pinterest unofficial API approach: reading the same public resource and RPC JSON the pinterest.com web app uses, without going through app approval.

Why the official API falls short here

Pinterest’s v5 API gap is about access posture, not documentation quality. To use it for reading public data you have to:

• Register an app and pass review to leave trial/standard access.
• Work within OAuth scopes that center on the authenticated user’s own resources.
• Live with rate limits tuned for account management, not bulk public reads.

There is no clean, approval-free path to “give me the top pins for this search term” or “dump this public board.” The public data renders fine in a logged-out browser, but the documented API does not hand it over without the gating. That is the gap the Pinterest unofficial API route fills.

What data is actually available

From the public web surface you can reach:

• Pins — title, description, the full-resolution image (and video URL for video pins), the source/destination link, dominant color, board it belongs to, pinner, repin (save) and comment counts, and rich-pin metadata (product price, recipe, article) when present.
• Boards — name, description, owner, pin count, follower count, section list, and the board’s pins.
• User profiles — username, display name, bio, follower / following counts, board list, and pin/save counts.
• Search — pins and boards matching a query, paginated, plus related queries.

This is the same content a signed-out visitor scrolls; you are reading it through the client’s own data calls.

How the public resource and RPC surface works

The Pinterest web app is a single-page app that fetches data through internal JSON endpoints rather than a public REST API. Two mechanisms matter:

• The resource endpoint — the web app calls /resource/<ResourceName>Resource/get/ style URLs (for example a pin resource, a board feed resource, a base search resource) with a URL-encoded data parameter carrying an options object: the pin/board ID or the search query, plus paging fields. The response is JSON in the app’s resource_response envelope.
• Embedded initial state — the first HTML response also embeds a hydration blob (the app’s initial Redux/__PWS_DATA__-style state) containing the pin, board, or first search page. Parsing that gives you page one without a separate call.

The reliable pattern is: fetch the public page, read the embedded initial state for the first batch, then page forward through the resource endpoints. Send the headers and CSRF/cookie values the web app sends so the resource calls are accepted rather than rejected.

Pagination with bookmarks

Pinterest feeds paginate with a bookmark cursor. Each resource response returns a bookmark (or a bookmarks array); you pass it back in the next request’s options to fetch the following page. When the returned bookmark is the end sentinel (commonly -end-) or no bookmark comes back, you have reached the end of the reachable feed. Notes:

• Search and board feeds can be long but not infinite logged-out; expect a bounded window rather than the entire history.
• The same pin can recur across pages in a feed; dedupe by pin ID.

Rate limits and how to live with them

No published quota applies to the web surface, so you are managing Pinterest’s bot defenses:

• Pace requests with jitter and avoid bursts from a single IP.
• Rotate IPs for volume; sustained feed paging from one datacenter IP degrades quickly.
• Carry a consistent cookie/CSRF context per session rather than firing cold requests.
• Back off on empty or error envelopes — an empty resource_response data block usually means throttling, not end-of-feed.

A clean output schema

Normalize each pin into a flat row:

{
  "pin_id": "1140000000000000000",
  "type": "pin",
  "url": "https://www.pinterest.com/pin/1140000000000000000/",
  "title": "Minimalist kitchen ideas",
  "description": "Light wood and white tones for a small kitchen.",
  "image_url": "https://i.pinimg.com/originals/ab/cd/ef.jpg",
  "is_video": false,
  "video_url": null,
  "dominant_color": "#e8e1d6",
  "link": "https://exampleblog.com/kitchen-ideas",
  "board_id": "1130000000000000000",
  "board_name": "Home Inspo",
  "pinner_username": "examplepinner",
  "save_count": 4821,
  "comment_count": 37,
  "rich_type": "article",
  "query": "minimalist kitchen",
  "scraped_at": "2026-06-08T09:35:00Z"
}

Keep pin_id and board_id as join keys, and store query when the pin came from a search so you can analyze rankings per term.

▶ Try the Pinterest Scraper on Apify — pulls pins, boards, profiles, and search results through the public resource surface. No app approval, no trial access.

Use cases

• Visual trend research — track which pins and styles are saved most under a search term over time.
• Board and competitor monitoring — watch a brand’s boards for new pins and link destinations.
• Affiliate and product discovery — pull rich/product pins with their outbound links and prices.
• Dataset building — collect pins and metadata across a set of queries or boards for analysis.

Every dependable use case starts from a known pin, board, profile, or search term, which is exactly what the resource surface exposes.

Build it yourself vs. a managed actor

You can build this against the resource endpoints, but the friction is real: the resource names and options shapes change, the bookmark sentinel handling is easy to get wrong, the CSRF/cookie context has to be maintained, and the resource_response envelope nests differently per resource type. The first version works, then a web-app update renames a resource and your paging stalls silently. A managed actor keeps the resource names, envelopes, and bookmark logic current and handles rotation, so you collect pins and boards instead of chasing app changes.

Common pitfalls

• Mis-handling the bookmark sentinel — treat -end- (or a missing bookmark) as end-of-feed, not as a valid cursor.
• Skipping the embedded initial state — you waste a call re-fetching page one.
• No CSRF/cookie context — resource calls get rejected.
• Reading empty envelopes as end-of-feed — they often mean throttling.
• Assuming the full board history logged-out — the window is bounded.

Wrapping up

The v5 API gates public reads behind app approval and account-centric scopes, so the Pinterest unofficial API route — the public resource and RPC JSON surface — is the practical way to pull pins, boards, and search data in 2026. Read the embedded initial state, page through the resource endpoints with bookmarks, maintain a cookie/CSRF context, and rotate IPs. Build around known pins, boards, and queries, and let a managed layer absorb the web-app churn.

▶ Open the Pinterest Scraper on Apify — pins, boards, profiles, and search with clean rows, paid per result. Skip the approval queue.