How to Schedule Dribbble Shots: API Access, Upload Scope, and a Working Setup

Short answer: Dribbble does not schedule shots for you, natively or through the API. Long answer: the API v2 is self-serve, it can upload a shot on your behalf, and once you understand its two scopes and its rate limits, building your own posting calendar around it is a weekend of work, not a month of it.

This is the complete picture for anyone who has typed "how to schedule Dribbble posts" into a search bar and come back with nothing but forum threads from 2019.

What you need (OAuth app, upload scope, likely Pro)

Before you write anything, you need:

• A Dribbble account, ideally the one you post shots from.
• A registered OAuth application at developer.dribbble.com. This is self-serve, no waitlist, no review queue to sit in.
• The upload scope specifically. The default public scope only lets you read data, it cannot create a shot.
• A Dribbble Pro subscription. Upload access has historically been gated behind Pro, though Dribbble does not spell this out cleanly in current docs, so treat it as likely rather than confirmed until you hit the wall yourself.
• A shot image that meets Dribbble's own upload requirements (dimensions, file size, format), which the API enforces the same way the web uploader does.

That's the whole prerequisite list. No app review, no business verification, no advertising-restriction traps. Dribbble's onboarding is refreshingly boring compared to what you'll find in our guides to the Instagram API or the TikTok Content Posting API.

Registering at developer.dribbble.com

Head to developer.dribbble.com and register a new application. You'll get a client ID and client secret, plus you set a callback URL for the OAuth redirect. Dribbble's OAuth flow is the standard authorization-code dance: redirect the user to authorize, exchange the code for an access token, then attach that token as a bearer header on every API call.

Two scopes matter here:

• public covers read-only access to profile and shot data.
• upload is required to create shots and is the one that gates the whole workflow. Request it explicitly when you build your authorization URL, it is not included by default.

Once you have a token with upload scope, you're set up to publish.

Uploading a shot via API v2

API v2 is deliberately narrow. Where the old v1 API exposed a public feed you could browse and filter, v2 removed those endpoints. It is, in practice, a publish-your-own-shots API rather than a discovery API. That's a meaningful shift if you were hoping to pull trending shots or build a browsing client. You can't, at least not through the official API.

What you can do is create a shot on your own profile. The upload call takes your image plus metadata: title, description, tags, and the team or project it belongs to if you have one. Successful creation returns the shot object, including its ID and public URL, which you'll want to log for anything you build downstream (a "posted" tracker, a promo queue, whatever your workflow needs).

Dribbble's API terms are also worth reading once. They explicitly permit commercial use of the API, as long as you're not rebuilding Dribbble itself, which is a fair line and one worth knowing exists before you build a business on top of it.

See how TimeToPost can help you implement these strategies.

No schedule field: the external-scheduler pattern

Here's the gap. There is no scheduled_at, no publish_at, nothing in the shot-creation payload that tells Dribbble to hold your upload and fire it later. Every shot you send through the API goes live the moment the call succeeds.

If you want a shot to appear at 9am Thursday, the API will not do that for you. The pattern that actually works is the same one that shows up across half the platforms without native scheduling: you hold the post yourself, on your own clock, and fire the API call at the moment you want it live.

Concretely, that means:

1. Prepare the shot (image, title, description, tags) ahead of time.
2. Store it somewhere with an intended publish time attached.
3. Run a timer, cron job, or a scheduler product that watches that queue and calls the upload endpoint at the right moment.

This is exactly the shape of the workaround we describe for Dev.to and other API-only platforms: draft now, publish later, by holding the trigger yourself instead of asking the platform to hold it.

A calendar workflow for design drops (TimeToPost)

Dribbble isn't a connected platform in TimeToPost yet. What TimeToPost is genuinely good for today is everything around the shot: the calendar that holds your design drop dates, the best-time data that tells you when your audience is actually looking, and the promo posts that go out on X, Instagram, or wherever else you announce new work.

A workflow that holds up in practice looks like this. Put your Dribbble drop dates on the same calendar as your X and Instagram promo posts in the social media scheduler, so the shot going live and the "new shot is up" post aren't two separate mental todo lists. Use best-time-to-post data to decide when your promo posts fire, since that's the part of the funnel where audience attention actually matters most. Keep the Dribbble upload itself on its own small script or cron job, since that's the piece the API can execute but not schedule.

It's not a one-click connector for Dribbble. It's the layer that keeps a design drop from being a shot that goes live and then sits there because nobody posted about it anywhere else.

Limits: 60/min, 1,440/day

Dribbble's rate limits are published and specific:

• 60 requests per minute per access token.
• 1,440 requests per day per access token, which works out to the same 60/minute ceiling spread across a full day, so in practice the daily cap rarely bites unless you're running a very chatty integration.
• Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so you can track your budget live instead of guessing.
• Go over either limit and you get a 429, same as most well-behaved APIs.

For a workflow that's uploading a handful of shots a day and occasionally reading your own profile data, none of this is a real constraint. It becomes relevant if you're building something that also pulls comments, likes, or follower data on a tight loop, in which case budget your polling accordingly.

FAQ

Is the Dribbble API approval-gated? No. Registering an OAuth application at developer.dribbble.com is self-serve, no waitlist and no review process to submit through. Getting the upload scope working reliably may still require a Pro subscription, which is the closest thing to a gate here, though Dribbble doesn't document that requirement explicitly.

Are commercial tools allowed to use the API? Yes. Dribbble's API terms explicitly permit commercial use, with the condition that you aren't cloning Dribbble's own product or feed experience. Building a scheduler, a portfolio sync tool, or a client dashboard on top of it is within bounds.

Does native scheduling exist for Pro accounts? This isn't documented or verified anywhere reliable. If Dribbble Pro does have an internal scheduling feature for the web uploader, it isn't exposed through the API, and we'd rather flag it as unconfirmed than claim it exists.

Can the API read the public feed or other people's shots? Not anymore. API v2 dropped the public feed endpoints that v1 had. What's left is scoped to your own account: your shots, your profile, your uploads. If you need broader Dribbble data, the API isn't the route.

If you're building a design-drop calendar that spans more than just Dribbble, that's the part TimeToPost is built for today.