Pinterest Shopping feed setup: fields and image specs

Here is the quirk that catches teams who already run Meta, Google, and TikTok catalogs: Pinterest wants portrait images, not square ones. The required fields are almost identical to a Google Shopping feed, so the data side is easy. But Pinterest's catalog floor is 1000×1500 pixels at a 2:3 ratio, while every other major channel optimizes for a square 1:1. A feed that is perfect for Meta can still under-deliver on Pinterest purely on image shape. This walks through the required catalog fields, the image and format specs, the prerequisites Pinterest handles on its side, how a hosted feed URL connects, and the numbered errors that keep products from publishing.

The required catalog fields

Pinterest requires 7 fields on every product, plus one conditional field for variants. If you have built a Google Shopping feed before, this list will look familiar: it is the same core set, which is exactly why an RSS 2.0 feed shaped for Google is nearly Pinterest-ready out of the box.

Beyond the required set, Pinterest treats attributes like condition, brand, google_product_category, product_type, color, size, gender, sale_price, gtin, and custom_label_0 through 4 as recommended for discovery and segmentation, not as hard requirements. Send them when you have them, but a product publishes on the 7 required fields alone.

Two fields deserve a careful note, because their exact accepted values are easy to get wrong. For price, send a number with a currency that matches the currency you select when you add the data source. Pinterest does not publish a single verbatim format string on its help pages, so the safe rule is: keep the number well-formed, keep the currency consistent with the source setting, and a mismatch or a malformed value triggers error 113 or 151 (covered in the rejection table below). For availability, the cleanly confirmed values are in_stock and out_of_stock; other states such as a preorder value appear in third-party guidance but are not something to rely on as an official Pinterest enumeration. The load-bearing fact is that out-of-stock products drop out of both organic and paid distribution.

Image and format specs

This is where Pinterest diverges from the rest of your catalog stack. Two numbers matter and they should not be conflated: the catalog ingestion floor (the hard gate that decides whether an image is accepted at all) and the recommended Pin ratio (a creative best practice for how the Pin displays in feed). The happy coincidence is that 1000×1500 satisfies both at once.

That format row is the one that makes Pinterest straightforward for a served feed. Pinterest explicitly accepts XML RSS 2.0, which is the same RSS 2.0 structure you would build for Google. If you want to understand that file shape end to end, the build-a-Google-feed-by-hand walkthrough builds the minimal RSS 2.0 skeleton attribute by attribute, and that same file is the starting point for Pinterest.

One more framing point on imagery: avoiding promotional overlays and urgency text on Pins is a Pinterest advertising-policy and creative best-practice stance, not a documented feed-spec rejection. The hard image rules at ingestion are the 1000×1500 floor and the no-placeholder requirement. If you want to add multiple shots per product (which the 75×75 additional-image minimum allows), the multi-image catalog ads guide covers how extra images flow through a feed.

Prerequisites Pinterest handles on its side

Before a catalog data source will work at all, Pinterest needs four things set up at the account level. These are not feed fields and no feed tool can produce them; they are merchant setup you complete inside Pinterest:

• A Pinterest business account. Catalogs are a business-account feature.
• A claimed website. You verify ownership of your domain in Pinterest.
• The Pinterest tag installed. The conversion tag on your site.
• A site that meets Pinterest's merchant guidelines. Products that violate those guidelines or ad policies are not uploaded or distributed.

Keep this boundary clear: the feed itself only covers the per-product data and image URL. The account, the domain claim, and the tag are separate one-time setup steps you do in Pinterest before you ever add a data source. Pinterest can process up to 20 million products per retail catalog, so capacity is rarely the constraint; setup and field hygiene are.

Connecting a hosted feed URL

Once the account-level prerequisites are in place, a hosted feed connects through a single flow. In Pinterest: log in, go to Catalogs, choose Add data source, open the Provide URL link tab, then fill in the source name, the feed URL, the file format, the country, the language, the currency, and a default availability. Pinterest tests and validates the source, and you finish by creating Pins.

The URL rules

The hosted URL has to meet a few connection requirements, and they line up exactly with how a served HTTPS feed behaves:

• Protocol. The URL must begin with http://, https://, ftp://, or sftp://. A plain HTTPS direct-download link is the common case.
• Port. Port numbers must be 80 or 443.
• No credentials in the URL. The URL must include the full filepath and no credentials; no extra navigation, IP whitelisting, or SSH-key access may be required to reach the file.

How often Pinterest pulls it

For a hosted URL, Pinterest ingests the data source once every 24 hours. That is a pull on Pinterest's schedule, not a push you trigger: Pinterest fetches the URL on its own roughly 24-hour cycle, and products surface once they are processed. There is no published hour-by-hour review SLA beyond that ingestion cycle, so plan around the daily cadence rather than expecting instant updates.

Manual uploads behave differently and are worth avoiding for anything that changes: a manually uploaded file must be refreshed every 7 days to keep organic distribution, and after 90 days without an update, ad distribution stops. A hosted URL sidesteps that decay entirely, because Pinterest keeps re-fetching it.

Common rejection reasons

After ingestion, Pinterest surfaces issues in the catalog's Diagnostics tab under View Errors and Warnings, split into ingestion issues (failed to upload, or warnings) and distribution issues (ineligible for ads, or ineligible for organic). The important distinction: a missing required field fails that specific item so it will not be published, while some required-field errors or a malformed file can fail the entire catalog ingestion. Pinterest documents numbered error messages, and these are the ones worth pre-empting:

A few non-numbered ingestion gotchas cause the same kind of failure. Mismatched delimiters (a stray comma or tab so rows do not all have the same column count) fail the item or the whole file. Reusing an item id that already exists in another data source on the same catalog surfaces as an error. And anything that violates merchant guidelines or ad policies is simply not uploaded or distributed. Most of these collapse to the same advice: validate the required fields and image specs before the feed reaches Pinterest's ingestion queue.

Square for Meta, portrait for Pinterest

If you run catalogs across channels, the cleanest answer to the square-versus-portrait split is not to compromise on one shared image. It is to keep a square 1:1 template for Meta, Google, and TikTok, and a separate 2:3 portrait variant sized at 1000×1500 for Pinterest, each served from its own URL. The same source products, two image treatments, no cropping surprises.

That is the pattern Emberfeed's Duplicate flow exists for: it clones a feed against the same source URL but with independent rules and its own template, so a Pinterest-bound copy can render the portrait ratio while the original stays square for everything else. You point each served URL at the channel it belongs to. The same approach to getting a usable source feed in the first place is covered in the Shopify product feed setup guide, and the per-product render side is in AI-designed catalog images.