Pinterest API Guide for Developers (2026)

The Pinterest API v5 will create pins for you, including video pins, but only after your app clears a review. Until then your app sits in trial access, where every pin and board it creates is a sandbox entity visible to nobody but its creator. That single fact decides whether the API is useful to you, so it belongs at the top rather than buried in a section on scopes.

What can the Pinterest API actually publish?

It creates pins on boards owned by the authenticated account: image pins and video pins, with a title, description and destination link. It is a publishing API, not a browsing API, and it is scoped to accounts that have authorised your app.

The gaps that matter to an evaluation:

So an internal tool you use on your own account can live on trial access indefinitely. A product that publishes on behalf of customers cannot, because trial pins never become visible.

Note: Figures here were verified against developers.pinterest.com as of September 2026. Platforms change these without notice.

What does Pinterest app review require, and how long does it take?

You register an app, get approved for trial access, then request the upgrade to standard. Pinterest’s documentation states the upgrade requires that your app already has trial approval, complies with the Developer Guidelines, and that you supply a video recording of your app completing an action through the Pinterest API, with the user authentication flow visible in the recording. Screen recordings of terminal calls or Postman are accepted formats.

The most common rejection reason Pinterest names is a demo that does not show the OAuth flow, or that does not show live Pinterest integration inside the application.

On duration: Pinterest says standard upgrade requests are “reviewed regularly” and that you are notified by email when a decision is made. It suggests allowing a few days. No specific turnaround time is published, so treat any precise number you read elsewhere as a guess. Plan your launch date around an unknown, not around a promised SLA.

The auth model itself is ordinary OAuth 2.0: redirect the user to Pinterest, exchange the code for an access token and a refresh token, store both per account, refresh before expiry. Nothing exotic. The exotic part is the review gate in front of it.

What is the actual sequence to create a pin?

For an image pin sourced from a public URL, it is one call. For a video pin it is four steps, because the bytes have to be registered, uploaded and processed before a pin can reference them.

1. Register the media upload. POST /v5/media with the media type. The response carries a media identifier, an upload URL and a set of form parameters.
2. Upload the bytes. POST a multipart form to that upload URL, sending the returned parameters as form fields first and the file last. This is an S3-style presigned form post, not a Pinterest endpoint, so its error responses are XML rather than JSON.
3. Poll the media status. Read the media record back until processing has succeeded. The upload returning a 2xx does not mean the video is usable.
4. Create the pin. POST /v5/pins referencing the processed media, plus the board, title, description and link.

# 1. register
curl -X POST https://api.pinterest.com/v5/media \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"media_type":"video"}'

# 2. upload the bytes to the returned upload_url,
#    sending every returned upload parameter as a form field first
curl -X POST "$UPLOAD_URL" \
  -F key="$KEY" -F policy="$POLICY" -F "x-amz-signature=$SIG" \
  -F file=@clip.mp4

# 3. poll until the media reports a succeeded status
# 4. create the pin referencing that media id

Note: We could not verify the exact request and response field names for POST /v5/media or POST /v5/pins against the official Pinterest API reference: those pages render their content client-side and did not return documentation text when fetched. Read the live API reference on developers.pinterest.com before writing against them, and treat the field names above as the shape of the flow rather than a copyable schema.

The step people skip is the third one. A video pin also needs a cover image, which is a second asset to produce and validate. We could not confirm the exact cover requirement on a fetchable v5 reference page, so verify it against the current docs before you build around it. If you are sizing images for either kind of pin, our Pinterest post sizes guide has the current dimensions.

What are the Pinterest API rate limits?

The published limits differ sharply by tier, which is another reason trial access is not a preview of production behaviour.

Individual endpoint categories carry their own narrower limits on top of the universal one: read, write, analytics and conversions each have their own budgets, and Pinterest’s own documentation notes that all rate limits are subject to change without notice. Check the category assigned to each endpoint you call rather than assuming the universal number applies.

Note: Figures here were verified against developers.pinterest.com as of September 2026. Platforms change these without notice.

What will actually cost you three weeks

Not the pin call. The pin call is an afternoon. The three weeks are here:

• The review. You cannot ship to customers on trial access, and there is no published turnaround. Submit early, and submit a recording that clearly shows the OAuth flow, because that is the named failure mode.
• Token refresh. Refresh tokens expire and revocations happen silently. You need a stored refresh token per connected account, a job that renews ahead of expiry, and a “reconnect this account” state in your UI. Building this after the first customer’s token dies is the expensive order.
• Media transcoding. Video pins mean accepting whatever a user uploads, normalising codec and container, generating a cover image, and storing the result somewhere the upload step can stream it from. That is a media pipeline, not an API integration.
• Async failure handling. A 2xx from the presigned upload means the bytes arrived. It does not mean the video processed, and it does not mean a pin exists. You need a status poller, a retry policy that distinguishes transient from permanent failures, and a post state that can be processing rather than only published or failed. We wrote about that state model in the social media scheduling API guide.

Multiply all four by every platform you add. That is the real shape of the build. The build vs buy comparison puts numbers around it.

The short version

• Trial access is the default and produces sandbox pins visible only to their creator. Standard access requires a review with a video demo of the OAuth flow. No turnaround time is published.
• Image pins from a public URL are one call. Video pins are register, upload, poll, create, plus a cover image.
• Trial is limited to 1,000 requests per day per app. Standard is 100 requests per second per user per app, with narrower per-category limits underneath.
• The engineering cost is review, token refresh, transcoding and async failure handling, not the publish call.

Doing this once instead of once per platform

If Pinterest is one of several networks you need, the per-platform work above repeats with different shapes each time: different review gates, different media flows, different quota models. That is what our API exists to absorb. BulkPublish publishes to 15 platforms through one REST endpoint and one post model, with the OAuth, token refresh, media handling and async status tracking on our side.

The developer docs and the REST API integration page cover the endpoints and the post lifecycle. If you would rather schedule pins through an interface than write against either API, how to schedule Pinterest pins covers that path, and the free Pinterest character counter will keep your titles and descriptions inside the limits.

Related

• Social Media Scheduling API: A Complete Guide
• Build vs Buy: A Social Media Posting API
• Social Media API Rate Limits
• How to Schedule Pinterest Pins
• Pinterest Post Sizes