I run a visa agency in Bali, and the other half of my week goes into Apify Actors. The Pinterest one answers a question marketing people ask constantly: for this niche, which websites is Pinterest actually sending clicks to? One run, group the rows by domain, done.
On 3 November 2026 I ran it on minimalist kitchen and the answer came back as a list of websites I had never heard of — pinned by accounts with zero followers, zero pins and a name that starts with preview_.
The run
Pinterest search, pins scope, 20 pins, engagement switch on, 3 November 2026, no login. Pinterest Scraper on a plain Apify account.
| Rows | 20 of 20 asked for, zero errors |
| Run time | 10.8 s |
| Pins with an outbound link | 12 of 20 |
…of those, pinned by a preview_ account | 9 of 12 |
Pinners with a preview_ username | 9 of 20 |
title filled | 18 of 20 |
saves filled | 0 of 20 |
reactions filled | 2 of 20 |
| Charged | pin ×20 = $0.03, pin-details ×0 |
Nine of the twenty results were pinned by preview_roomhint_com, preview_linbiepham_com, preview_miscaluxe_com, preview_elodiestyling_com, preview_prettynestdecor_de, preview_wishonbrithday_com, preview_38f117427e82883f95d280 and preview_bd3b790782095ce502293e. Every single one of those nine pins carried a title and an outbound link. The eleven ordinary accounts in the same twenty produced three links between them.
What a preview account looks like from the profile endpoint
So I fed six of those usernames back in as profile inputs. Six profile rows, 2.1 s, $0.012:
| field | all six |
|---|---|
fullName | Pinterest Preview <the username's tail> |
followers | 0, 0, 0, 0, 2, 3 |
pinCount | 0 on five of six (26 on the sixth) |
boardCount | 1 |
websiteUrl | null |
monthlyViews | −1 |
imageUrl | s.pinimg.com/images/user/default_280.png |
createdAt | 15–21 October 2026 |
Two things in there are worth stopping on.
monthlyViews is −1, on all six. The field comes from Pinterest's profile_reach, and −1 is not a number of views — it is a sentinel meaning "not computed for this account". If you average that column across a sample, every preview account drags your mean down by one view and silently turns into a real data point. I treat anything below zero as missing now, and so should any aggregation you write on top of these rows.
websiteUrl is null — on accounts whose entire purpose is to represent a website. The domain is in the username (preview_miscaluxe_com → miscaluxe.com) and in each pin's link, and nowhere in the field named for it. Two of the nine are named with hex instead of a domain (preview_bd3b790782095ce502293e), and those still link out to ordinary sites — homestorageorganizer.com and cozykitchenandliving.com — so the hex is an opaque id for a domain, not the absence of one.
These are not dead accounts, either. I checked every domain the nine pins pointed at: roomhint.com, linbiepham.com, elodiestyling.com, prettynestdecor.de, miscaluxe.com, wishonbrithday.com, cozykitchenandliving.com — 7 of 7 answered 200 with real titles ("RoomHint | Storage, Organization & Room Ideas That Work", "Misca Luxe: Bathroom Fixes & Kitchen Cabinet Ideas"). Small content sites, all created-or-indexed in the last few weeks, all getting distribution through an account they appear not to have had to build.
Their pins only exist in search
Here is the part that breaks the obvious next step. Having found nine interesting publishers, the natural move is to walk each profile and see everything they pin. All six preview profiles returned zero pins. The profile feed is Pinterest's _created tab, and for these accounts it is empty — consistent with the pinCount: 0 in the row, and completely inconsistent with the pins I was holding in my hand from the same run.
Their board is no help either. The boardUrl on those nine pins is /preview_<domain>/_inspo/ — one board, named _inspo, and Pinterest's board endpoint does not serve it. Pass that URL in and the scraper reads it as a profile instead, because a path segment starting with _ is a profile tab (/_created/, /_saved/), not a board slug. Across 60 pins from three keywords, 13 pointed at an underscore board: 11 _inspo and 2 _quick_saves.
So the only place these pins are reachable is the search index. For a traffic-sources report that is fine — search is where you were looking anyway. For "show me everything this competitor publishes" it is a dead end, and the dead end is not in my code.
What it changes practically: don't filter a Pinterest sample by follower count. The obvious cleanup — drop pinners under 10 followers as noise — would have deleted three quarters of the link data on this keyword. The accounts holding the links are supposed to have no followers.
The entry point decides the ID format, and the bill
The same run also settled something I had been guessing at. I pulled one account two ways at once — its board, and its profile — 20 pins from each:
| board feed | profile feed | |
|---|---|---|
| Pins | 20 | 20 |
Numeric pinId | 0 of 20 | 20 of 20 |
| Engagement lookups charged | 0 | 20 |
Pinterest has been moving logged-out pin pages to opaque tokens — e1_AfqPShxPH41hAo83UO7dgaAaDCq5sJaNsLtv3S…, 55-plus characters — and its own pin endpoint answers Pin not found on them. I measured that on search results last week, with the search-only Actor. What I did not expect is that two feeds belonging to the same account in the same run disagree: the board feed hands out tokens, the _created profile feed still hands out numeric ids like 1063131055810574252. Numeric ids answer the pin endpoint, so the "exact saves and comments" switch fired on exactly the 20 profile pins and silently did nothing for the 20 board pins.
The bill shows it: profile ×1, pin ×40, pin-details ×20 = $0.072. Twenty detail lookups, forty pins. If you want engagement numbers, enter the account by profile, not by board — and if an Actor charges you per detail lookup, check that it is not charging for the ones that came back empty.
The boardUrl did not round-trip, and that one was mine
While measuring the above I fed a boardUrl from a search result straight back in as an input, which is the most obvious thing a user will ever do:
https://www.pinterest.com/cornerrenovation/kitchen-design-tips-guides-%2B-checklists/ → board not found. Not charged. Pinterest writes its own board URLs percent-encoded. Its BoardResource wants the decoded slug — kitchen-design-tips-guides-+-checklists. I was splitting the path and passing the segments through raw, so %2B went out as three characters and Pinterest 404'd. Three lines:
// Pinterest's own board URLs come percent-encoded ('…-%2B-checklists'), but its BoardResource // wants the decoded slug — feeding a boardUrl straight back answered 'board not found'. const unesc = (x) => { try { return decodeURIComponent(x); } catch { return x; } }; const parts = u.pathname.split('/').filter(Boolean).map(unesc); Before: 0 pins, board not found, charged $0. After, same URL, same build pipeline: 3 pins, 4 s, each with its outbound link to cornerrenovation.com/blog/…. The try/catch is not decoration — a malformed escape like %E0%A4%A throws, and a bad input should degrade to "slug not found" rather than killing the run. Search and profile inputs re-verified on the same build before the latest tag moved.
And one hypothesis the numbers killed
My first reading of the board feed was "it strips the text fields" — 20 board rows with title, description and link all null. That was wrong, and it was wrong in the most ordinary way: the account I happened to test publishes untitled, unlinked image pins. Its own numeric profile pins, detail lookup and all, came back equally empty. A second board from a different owner, 10 pins, same build: title 10 of 10, description 10 of 10, alt text 10 of 10.
So the board feed is fine. One account's content was the finding. If a field is empty across your whole sample, check a second source before you write it down as an API limitation — I nearly shipped a README note saying the opposite.
Calling it
curl -X POST "https://api.apify.com/v2/acts/lergassy~pinterest-scraper/runs?token=$APIFY_TOKEN" \ -H 'content-type: application/json' \ -d '{"searchQueries":["minimalist kitchen"], "urls":["https://www.pinterest.com/minimalistliving01/"], "maxPinsPerSource":50, "onlyWithLink":true}' onlyWithLink is the switch I use for traffic work: on boho bedroom it would have dropped 14 of 20 rows, because pins uploaded straight to Pinterest point nowhere. Link coverage swings hard by keyword — 19 of 20 on air fryer recipes, 12 of 20 on minimalist kitchen, 6 of 20 on boho bedroom — so your traffic denominator is the linked subset, never the row count.
When not to use this. If you need saves and comments at scale, this is the wrong road: go through a business account and Pinterest's official API, which is what those numbers are for. If you want everything one creator ever pinned, enter by profile and accept that preview accounts will return nothing. And if you are trying to study the sites behind a niche rather than the pins, the links are the whole product — pull them, group them, and then go read the sites.
Three keywords, 60 pins, under thirty cents. The useful output was not a ranking. It was a list of seven live content sites I would never have found by searching the web, plus the knowledge that Pinterest is handing them the distribution.

