Pinterest Scraper

Search Pinterest and get pins back as structured rows: the title, the description, the full-size image, the link and domain behind the pin, the board it sits on and who pinned it.

No login, no cookies, no browser.

What each pin gives you

• title, description and alt_text. The alt text is worth knowing about: Pinterest auto-generates it, so it is often filled in on pins whose title is empty, which makes it a useful fallback rather than a duplicate.
• image_url, plus image_width and image_height. This is the largest published rendition, not the thumbnail. Pinterest keys its renditions by width, so taking the first one you find gives you whichever happened to serialise first, which is usually a 236-pixel preview.
• link and domain — where the pin points. See the note below on what domain deliberately does not contain.
• board_name, board_url, pinner_username, pinner_full_name and pinner_followers
• reactions, summed across all reaction types
• is_promoted, so paid placements can be filtered out of any ranking
• dominant_color, which Pinterest computes for each image
• created_at and a direct url to the pin

Two details that keep the output honest

"Uploaded by user" is not a domain. Pinterest writes that phrase into the domain field for pins uploaded straight to the platform rather than saved from a website. Storing it as-is means every count grouped by domain has a large fake entry at the top that looks like a real site. Those pins are reported with an empty domain instead, and the summary says how many carried a real one.

Save counts are not reported, because this endpoint does not carry them. The structure that would hold them is present on every pin and empty on every pin, measured across a full page. A column that is null on every row is worse than an absent one: it reads as "this pin has no saves" rather than "saves are not available here". Reaction counts, which are populated, are reported instead.

Paging

Pinterest hands back an opaque bookmark string with each response and expects it replayed verbatim on the next call. It signals the end of the results with a -end- sentinel rather than by omitting the field, so a scraper that treats any bookmark as "more data" re-requests the same last page until its budget runs out. This stops on the sentinel.

Expect roughly 18 to 25 pins per page.

Input

• Search terms — kitchen ideas, minimalist desk setup
• What to search — pins, boards or users. Pins is the usual choice.
• Pages per term, maximum pins per term, maximum search terms
• Terms in parallel and retries
• Request from country, optionally

Run summary

Pins returned, how many carried a title, a source link and a real domain, how many were promoted, and the number of distinct boards and pinners.

Those distinct counts are the useful health check on a run: a large pin count spread across very few boards usually means one prolific account rather than broad coverage of the topic.

What people use this for

Visual trend research. The pins surfaced for a term are what Pinterest currently considers relevant to it, so running the same terms over time is a readable signal of what a category looks like right now.

Traffic-source discovery. domain shows which sites are actually earning saves in a niche. Because pins uploaded natively are excluded from that field rather than lumped under a fake label, the resulting domain counts mean something.

Content and SEO research. title, description and alt_text together are a corpus of the language people use for a topic, written by people trying to be found for it.

Creator identification. pinner_username and pinner_followers across a set of terms produce a ranked list of accounts active in a niche.

Image sourcing. image_url is the full-resolution rendition, with width and height, so a downstream pipeline can filter by size before downloading anything.

Scale and cost

Each page is one request and returns roughly 18 to 25 pins, so a term at three pages costs three requests. Two terms at three pages each returned 135 pins in 12 seconds in testing, and a single term at two pages returned 43 pins in six.

There is no per-pin follow-up request, so the cost of a run is exactly the number of pages you asked for. Raising pages per term is the only thing that makes a run longer.

Notes

Everything is read at the moment of the fetch. Pinterest re-ranks results constantly, so two runs of the same term hours apart will legitimately return overlapping but different sets. pin_id is stable, so deduplicating across runs is straightforward.

Rows are deduplicated on pin_id within a run, so overlapping search terms give you the union rather than repeats.

Boards and users scope return the same shape with the pin-specific fields empty, since those records are boards and profiles rather than pins.