Pinterest Profiles, Followers & Pins — Try the interactive demo

Retrieve a bounded snapshot of accounts that follow a Pinterest profile. For the initial request, pass the numeric Pinterest user ID as the string userid; a username is not a substitute. The query parameters are individually optional in the contract, but the documented starting request uses userid. For continuation, use only a node_id and cursor actually supplied by a response, and omit userid, including its default, because userid takes precedence. Do not invent continuation values. Stop when no usable pair is available or a token repeats. Observed response: a successful recorded probe returned message: null, data.request_id and ten data.followers[] records. Each record included a node with username, fullName, entityId and id, plus cursor: null. Keep identifiers as strings. No usable continuation was observed, so these records do not establish a complete follower export. Unverified documented examples additionally show node.__typename, imageMediumUrl, imageXlargeUrl, isPrivateProfile and status. These extra fields are illustrative, not guaranteed by the probe evidence. Documented error examples show detail and headers.Error for HTTP 400, a detail[] array containing loc, msg and type for HTTP 422, and data.followers, request_id and status for HTTP 500; these error shapes were not observed in the recorded successful probe. This read lists followers, not the accounts the target follows, and does not provide private audience analytics.

Retrieve the available public accounts followed by a Pinterest profile. Supply the profile username in the query parameter named userid. Despite its name, this route takes a username, not the numeric userid used by the follower route. userid remains optional in the parameter contract, while the documented first-page workflow supplies a username. Omit bookmark for the first page. If a response supplies data.bookmark, keep the same username in userid and pass that token unchanged as bookmark. Stop on absent or repeated tokens and deduplicate returned IDs. A continuation token was observed, but another page was not requested, so pagination and exhaustive collection are not verified. Observed response: a successful recorded probe returned message: null, data.request_id, data.status set to ok, a nonempty data.bookmark and fifty data.followings[] records. Each record included node.username and node.id with cursor: null. Preserve IDs as strings; the observed collection-level bookmark, not those null record cursors, is the documented next-page input. Unverified documented examples additionally show node.__typename, entityId, fullName, imageMediumUrl, imageXlargeUrl, isPrivateProfile, type, board_count, follower_count, pin_count, domain_verified, is_default_image, is_verified_merchant, last_pin_save_time, pin_thumbnail_urls and recent_pin_images. Treat these example fields as illustrative rather than guaranteed. Documented error examples show detail for HTTP 400 and 500, and detail[] entries with loc, msg and type for HTTP 422; these errors were not observed in the successful probe. Following relationships describe accounts the target follows, not its followers, and do not establish endorsement, audience overlap or private interests.

Look up public profile metadata using the required username query parameter. Use the Pinterest account username, not its display name; the recorded successful request used a username. Availability can depend on profile visibility and data availability. Observed success: HTTP 200 with status: ok, request_id, message: null and a nonempty data.user. Probe metadata confirmed data.user.id, username, full_name, pin_count, follower_count, following_count and last_pin_save_time. The observed id was the quoted decimal string "32088353503445352". Preserve its exact digits as a string for a numeric-ID follower request; do not convert it to a JavaScript number. If another response encodes an ID as an unquoted JSON integer, parse its raw token losslessly before string conversion. Observed not-found result: an HTTP 200 response contained status: error, request_id, a message explaining that no data was found and data.user: {}. Check the business status and profile content rather than interpreting transport success or an empty object as a valid zero-count account. Keep missing counts distinct from zero. Unverified documented examples additionally include about, first_name, board_count, created_at, domain_verified, eligible_profile_tabs, image_medium_url, image_xlarge_url, indexed, interest_following_count, is_ads_only_profile, is_gco_account, is_inspirational_merchant, is_partner, is_primary_website_verified, is_private_profile, is_verified_merchant, node_id, partner, profile_cover.url, seo_description, seo_title and type. These additional fields were not individually confirmed by the supplied probe metadata and may be unavailable. Documented error examples show detail for HTTP 400, detail[] entries with loc, msg and type for HTTP 422, and data.user, request_id and status for HTTP 500; those HTTP error cases were not probed. Follower and following totals are profile metadata, not relationship lists or proof of exhaustive enumeration. This response is a snapshot; any count history must come from your own repeated observations.

Send GET /ping to check whether the service responds to a lightweight request. This operation takes no endpoint-specific query parameters or request body and returns no Pinterest profile, pin or relationship collection. Response evidence: the supplied HTTP 200 documentation example is an empty JSON object. No live probe was recorded for this operation, so no particular response fields, status strings, request identifiers or timing metrics are confirmed. Inspect the HTTP status and any returned body rather than requiring an undocumented JSON property. Use a bounded client timeout and low-frequency polling. A successful health request establishes only that the health route responded; it does not confirm Pinterest data access, the availability of a particular account, other endpoints, pagination or complete content coverage. Test a representative data operation separately when diagnosing those capabilities.

Retrieve the available public pin records for the account identified by the required string query parameter username. The parameter documentation permits a Pinterest username or account ID, but the recorded probe verified only a username. The default example_user is an illustrative value; replace it with the intended account. No pagination parameter is exposed. Observed response: a successful request for marthastewart returned HTTP 200 with status set to ok, request_id, message set to null and data.pins containing 25 records. The probe confirmed pin IDs, public board URLs, the account's pinner identity, images and outbound links. This is evidence of a returned collection, not a fixed page size or a complete account export. Additional documented fields, not individually confirmed by the probe metadata: each pin may include id, title, description, description_html, alt_text, created_at, domain, link, seo_title and seo_url; board contains id and name, pinner contains id and username, and images may contain a size-keyed entry such as images["236x"].url. The source example also includes comment_count, repin_count, reaction_counts.like, comments, grid_title, grid_description, dominant_color and flags such as is_video, is_repin, is_promoted and privacy. Treat these example fields as optional rather than a guaranteed record schema, preserve IDs as strings and handle absent text, images or links. Counts, where present, are record attributes rather than engagement history. The documentation also illustrates HTTP 400 with a detail string, HTTP 422 with detail entries containing loc, msg and type, and HTTP 500 with status, request_id and data.pins. These are unverified error examples, not observed failures or guaranteed error formats. Use returned source references for attribution and compare pinner identities before assigning authorship. An account's collection may contain saved content; neither inclusion nor a media URL grants ownership or reuse rights. This route does not expose pagination, private boards, restricted pins or deleted content, and its available collection must not be described as every pin associated with the account.

Search publicly discoverable Pinterest accounts with the required string query parameter username. Despite its name, this parameter accepts account-search text such as a username or partial name; the recorded probe used the multiword query martha stewart. Replace the illustrative example_user default with the intended search text. No page or cursor input is documented. Observed response: the recorded request returned HTTP 200 with status set to ok, request_id, message set to null and data.users containing 49 account records. The first result included username set to marthastewart, an id and full_name set to Martha Stewart; another candidate was MarthaWeddings. These observations establish candidate discovery for that query, not a fixed result count, guaranteed ranking, account ownership or an exhaustive directory. Preserve IDs as strings. Additional documented fields, not individually confirmed by the probe metadata: user records may contain image_small_url, image_medium_url, image_large_url, image_xlarge_url, board_count, pin_count, follower_count, last_pin_save_time, domain_verified, is_primary_website_verified and is_verified_merchant. The source example also includes contextual_pin_image_urls, pin_thumbnail_urls, recent_pin_images, node_id, type, blocked_by_me, explicitly_followed_by_me, is_ads_only_profile and is_default_image. Treat these as optional example fields, not a guaranteed schema; flags in this public search example are not evidence of an authenticated viewer's relationship with an account. Counts and verification flags, if present, are profile attributes rather than private analytics or independent proof of identity. The documentation illustrates HTTP 400 with a detail string, HTTP 422 with detail entries containing loc, msg and type, and HTTP 500 with status, request_id and data.users. No such error was recorded by the supplied probe, so these are documented examples rather than observed failure formats. Compare candidate usernames and available profile metadata rather than accepting the first match. A display name is not necessarily the username required by subsequent account requests. After a human or application selects a candidate, use its returned username for a separate profile lookup or pin request; search does not perform that enrichment automatically. Results may be ambiguous or incomplete, and this endpoint searches users rather than pins or boards.