What the Pinterest API Rate Limit Is, per App and per User

What is the Pinterest API rate limit?

Two ceilings govern the Pinterest API rate limit and the lower one is the one that stops you: a universal limit that applies to all requests, and a per-category limit that Pinterest applies on top of it. The rate limits reference states the universal figures as "Trial access: 1000 requests per day for all API requests" and "Standard access: 100 requests per second per user per app for all API requests."

The unit changes with the access tier, which is the detail most integrations get wrong. Pinterest's access tiers page spells it out: "Apps with Trial access are rate limited based on calls per day/per app," while "Apps with Standard access are rate limited at a more granular level at calls per minute/per user/per app." A Trial app has one shared daily budget no matter how many accounts it serves. A Standard app gets a fresh per-minute budget for every connected user.

Every endpoint belongs to exactly one rate limit category, and the category is published in Pinterest's own OpenAPI description as an x-ratelimit-category field. Pinterest also warns on the same page that "all rate limits are subject to change without notice."

What are the Pinterest rate limits for each category?

Twelve categories carry their own numbers. Trial figures are requests per day per app and Standard figures are requests per minute per user per app, except where the row says otherwise.

Which rate limit category does posting a Pin fall under?

Publishing falls under org_write, which is the tightest budget a scheduler touches: 300 calls a day on Trial and 100 calls a minute on Standard. Pinterest's published OpenAPI description, version 5.28.0 of the Pinterest REST API, tags each operation directly:

Video Pins cost two org_write calls rather than one. media/create registers the upload and returns an upload_url, the file itself is posted to that URL rather than to the API, and pins/create then attaches the finished media. Reading is far cheaper than writing on Standard access, at 1,000 a minute against 100, and analytics is cheaper than neither, at 60 a minute. A dashboard that polls per-Pin analytics for 200 Pins will hit org_analytics long before a publisher hits org_write.

The daily Trial ceiling is what catches people building their first integration. At 300 org_write calls a day, an app in Trial can create roughly 300 image Pins or 150 video Pins in 24 hours, shared across every account connected to it. That budget also explains a fair share of the reasons a Pin fails to publish during testing.

Where Pinterest's own numbers disagree

Pinterest publishes figures on two pages and in one spec, and they do not reconcile. Three gaps are worth knowing before you size a queue.

The universal Standard limit is 60 times the category limit it sits above. The rate limits page says Standard access gets "100 requests per second per user per app for all API requests," which works out to 6,000 a minute. The category table on the same page caps org_write at 100 a minute. The lower number wins, and Pinterest's own header example confirms that more than one window is enforced at once:

< x-ratelimit-limit: 100, 100;w=1, 1000;w=60
< x-ratelimit-remaining: 99
< x-ratelimit-reset: 1

That reads as 100 in a one-second window and 1,000 in a sixty-second window, which is neither 6,000 nor 100.

The universal Trial limit is higher than two category limits underneath it. Trial is described as "1000 requests per day for all API requests," yet ads_write and org_write are both listed at 300 per day in the category table.

The conversions endpoint contradicts its own category. The rate limits page puts ads_conversions at 120,000 requests per minute per ad account per app on Standard. The description of POST /v5/ad_accounts/{ad_account_id}/events, which carries x-ratelimit-category: ads_conversions, says in Pinterest's published spec: "This endpoint has a rate limit of 5,000 calls per minute per ad account." That is a factor of 24 between two Pinterest sources for the same endpoint.

Build against the smaller number in each pair. Pinterest does not state which page takes precedence.

What does a Pinterest 429 response look like?

Every endpoint in the spec documents a 429, described as "the user has sent too many requests in a given amount of time and is being rate limited." The body is Pinterest's generic error object, a JSON document with exactly two required fields:

{
  "code": 2,
  "message": "AdAccount not found."
}

That example is the one Pinterest ships in the spec for the shared error schema, not a rate limit example. Pinterest's error codes reference lists codes for customer lists, audiences and shopping feeds, and publishes no numeric code for a 429 at all. The spec documents no Retry-After header and no x-ratelimit-* response headers on any endpoint, even though the rate limits page demonstrates those headers in a cURL example. Treat the headers as real and the numeric code as undocumented, and key your retry logic on the HTTP status rather than on the body.

How do you stay under the Pinterest API rate limit?

Read the counters instead of guessing at them. Pinterest's documented method is to run requests verbosely and inspect the response, as in curl -v --location --request GET 'https://api.pinterest.com/v5/pins' --header 'Authorization: Bearer <token>', then track x-ratelimit-remaining against x-ratelimit-limit per category rather than per app.

Four habits keep an integration inside the budget:

• Budget per category, not per integration. A publisher, an analytics poller and a catalog sync draw on org_write, org_analytics and catalogs_write separately, so one of them saturating does not slow the others.
• Spread Standard-tier writes across the minute. At 100 org_write calls a minute per user, a burst of 200 queued Pins for one account needs two minutes of pacing, the same arithmetic that governs Bluesky's points budget and Instagram's 100 posts per 24 hours.
• Upgrade out of Trial before launch. Trial caps org_write at 300 a day for the whole app and, per the access tiers page, Pins and boards created on Trial "are only visible to their creator as Sandbox entities," so nothing you publish in testing is public anyway.
• Ask for more when you have outgrown the default. Pinterest's documented route is to file a ticket with its support team, which is also how you free a slot against the five-app limit its FAQ mentions.

If you are pacing a queue by hand rather than through an API client, the same per-minute arithmetic applies to scheduling Pinterest posts in bulk.

Frequently asked questions

How many Pins can I create per day with the Pinterest API?

On Trial access, about 300, because pins/create falls under org_write and Trial caps that category at 300 requests per day per app. On Standard access there is no published daily cap for org_write, only 100 requests per minute per user per app, which is 144,000 a day if you sustained it.

Is the Pinterest API rate limit per app or per user?

Both, depending on tier. Trial access is metered per day per app, so every connected account shares one budget. Standard access is metered per minute per user per app, so each connected account gets its own.

What HTTP status code does Pinterest return when rate limited?

429. Pinterest's OpenAPI description defines it on every endpoint with the description "the user has sent too many requests in a given amount of time and is being rate limited," and the response body is the generic error object containing code and message.

Which headers show my remaining Pinterest API quota?

x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset. The rate limits page shows them in a verbose cURL example, with x-ratelimit-limit carrying more than one window, as in 100, 100;w=1, 1000;w=60.

Does Pinterest publish a Retry-After value for 429 responses?

No. Neither the rate limits page nor the published OpenAPI description defines Retry-After on any endpoint. The only timing signal Pinterest documents is x-ratelimit-reset, shown with a value of 1 in its own example.

How do I get a higher Pinterest API rate limit?

Upgrade the app to Standard access, then file a support ticket. The access tiers page routes the upgrade through My apps and requires a video recording of the OAuth flow, and the rate limits page directs anyone wanting a further change to file a ticket with Pinterest support.

Is there a limit on how many apps I can register with Pinterest?

Pinterest's own FAQ mentions a five-app limit per developer account. The same support ticket route used to request a higher rate limit is also what frees a slot once you have outgrown that cap.

Do video Pins use more of the rate limit than image Pins?

A video Pin costs two org_write calls instead of one, since media/create registers the upload before pins/create attaches the finished file. That doubling means a Trial app's 300-call org_write budget covers roughly 150 video Pins a day, half the ceiling for image Pins alone.

Are Pins created on Trial access visible to anyone besides the developer?

Pins and boards created while an app holds Trial access are Sandbox entities, visible only to their creator, according to Pinterest's access tiers page. Testing against the 300-call org_write ceiling costs nothing in public exposure, since nothing published before upgrading to Standard access is public anyway.

How much less does reading cost than writing on Pinterest's Standard access?

org_read runs at 1,000 requests a minute per user per app on Standard access, ten times the 100 a minute that org_write allows. Analytics sits below both at 60 a minute. That gap is why a dashboard polling per-Pin analytics for 200 Pins hits its ceiling before a publisher hits org_write.