Pinterest's API enforces a universal cap of 1,000 requests a day for apps on Trial access and 100 requests a second for apps on Standard access, according to Pinterest's own rate-limits reference. But that headline number isn't the one a scheduler actually hits. Creating or updating a Pin, the one action every scheduler exists to do, falls under a narrower category called org_write, and on Trial access that category is capped at just 300 requests a day, not 1,000.
Pinterest's two access tiers set two different kinds of ceiling
Trial access is what every newly approved Pinterest app gets by default, and its limits are counted per day, per app, across every user that app serves combined. Standard access is Pinterest's production tier, and it recounts almost the same categories on a per-minute, per-user, per-app basis instead, a shape that scales with how many accounts a tool connects rather than capping the whole app at one shared daily number. Pinterest's access-tiers page also notes a catch that has nothing to do with request counts: Pins and boards created under Trial access are visible only to the developer who created them, as sandboxed test entities, until the app is approved for Standard.
| Category | Trial access (per day, per app) | Standard access (per minute, per user, per app) |
|---|---|---|
| Universal (every endpoint combined) | 1,000 requests/day | 100 requests/second |
| org_write: creating or updating Pins and boards | 300 requests/day | 100 requests/minute |
| org_read: reading Pins and boards | 1,000 requests/day | 1,000 requests/minute |
| catalogs_write: syncing a product catalog | 1,000 requests/day | 100 requests/minute |
Why org_write is the number that actually matters to a scheduler
There's no separate category for "create a Pin" in Pinterest's own documentation. Pin and board creation both fall under org_write, the same bucket used for less frequent actions like renaming a board. On Trial access that bucket is capped at 300 requests a day for the entire app, shared across every account the app has connected, not 300 per account. A tool still in Trial that connects even a handful of active accounts, each scheduling a normal daily batch of Pins, can burn through that 300-request ceiling well before any single account feels like it's posting a lot.
What a rate-limited request actually looks like
Pinterest documents that every endpoint can return a 429 when a category limit is hit, but it doesn't publish a specific error body or retry-after value for that response the way some APIs do. Pinterest's own newsletter to developers recommends watching the rate-limit headers returned on every response rather than waiting to get a 429 at all, since those headers report the live count against the current window. The documentation is also upfront that none of these figures are a promise: it states directly that all rate limits are subject to change without notice, which is the real reason a scheduler shouldn't hardcode 300 or 1,000 into its own logic as if either number were permanent.
How Synapse handles a Pinterest rate limit
Synapse's Pinterest integration runs on Standard access, not Trial. Pinterest approved Synapse for Standard in July 2026, which is what makes Pins and boards created through it visible normally rather than sandboxed to a single developer account. Reading the integration's code directly shows it doesn't run its own queue-and-backoff loop against Pinterest's limits: a rejected request surfaces as a plain error carrying Pinterest's own HTTP status, the same pattern used across every direct integration in the app. In practice that means a rate-limited Pinterest account in a batch shows up in that post's results as a failed account rather than disappearing silently, and Retry failed re-attempts only that one account once the window has reset, without re-posting the accounts that already went through. The same per-account isolation is what makes bulk-scheduling Pinterest Pins past the native 10-Pin queue, or scheduling a Pinterest video Pin in the same batch, safe to retry without double-posting anything that already succeeded.
What to check before you build or rely on a Pinterest scheduler
Frequently asked questions
What is Pinterest's API rate limit for schedulers?
Pinterest's universal cap is 1,000 requests a day for Trial access and 100 requests a second for Standard access, but Pin and board creation falls under a narrower org_write category: 300 requests a day on Trial, 100 requests a minute per user per app on Standard.
Why would my Pinterest scheduler stop working before I post very much?
If the connected app is still on Trial access, every Pin or board creation across every account the app serves shares one app-wide cap of 300 org_write requests a day, not 300 per account, so a handful of active accounts can exhaust it quickly.
What's the difference between Pinterest's Trial and Standard API access?
Trial counts most limits per day, per app, shared across all users, and Pins or boards it creates are visible only to the developer as sandboxed test entities. Standard counts the same categories per minute, per user, per app, with higher ceilings, and content is visible normally.
Does Pinterest publish a fixed retry-after time for a 429 response?
No. Pinterest documents that any endpoint can return a 429 on a rate-limit hit, but it doesn't publish a specific retry-after value. It recommends watching the rate-limit headers on each response instead of waiting for a 429 to happen.
Can Pinterest's API rate limits change without warning?
Yes. Pinterest states directly in its own documentation that all rate limits are subject to change without notice, so a scheduler shouldn't hardcode any specific number as permanent.
How does Synapse handle a Pinterest account that hits a rate limit mid-batch?
Synapse's Pinterest integration surfaces a rejected request as a plain per-account error rather than retrying automatically. That account shows as failed in the post's results, and Retry failed re-attempts only it once the limit window has reset, leaving already-published accounts untouched.