How to Schedule Posts on VK: Delayed Posts, publish_date, and Community Tokens
VK (formerly VKontakte) is one of the few major social platforms where scheduling is genuinely easy on both sides: the native community admin panel has a delayed-post button, and the API takes one extra parameter to do the same thing. No container dance, no audit wall, no waiting on App Review. If you run a VK community and you have been posting manually because you assumed the platform was locked down like everything else, it isn't.
The catch is that VK's own documentation is thin in places, so a lot of what circulates about limits (how many delayed posts you can queue, exact daily caps) comes from developer forums and community-compiled tables rather than an official rate-limit page. I'll flag every one of those clearly below so you know what's load-bearing and what's folklore.
What you need
- A VK community (group or public page), not a personal profile. Delayed posting through the admin panel and most reliable API posting both assume you're posting as a community, not as yourself.
- Admin or editor rights on that community if you're using the native scheduler.
- To use the API, a standalone VK app registered at vk.com/apps, which gets you a
client_idfor OAuth. - A community access token (the one you actually want for scheduled posting, more on this below) or a user token with the
wallpermission. - The VK API version pinned in every request, since VK breaks backward compatibility between versions more than most platforms.
Native delayed posts in communities
If you manage a VK community from the desktop web interface, the "Suggest news" or standard post composer has a clock icon next to the publish button. Click it, pick a date and time, and the post sits in a postponed state until it fires automatically. It shows up in its own tab in the community's wall management view, separate from published posts, so you can see everything you've queued at a glance.
This has existed for years and works well for the basics: text, images, video, polls. What it does not do is give you a cross-platform calendar. If your VK community is one channel out of five you run, you're still jumping into VK's own interface to manage that one queue while everything else lives somewhere else.
API scheduling: wall.post and publish_date
The API version of the same feature is a single extra parameter on the standard posting call:
POST https://api.vk.com/method/wall.post
owner_id=-<community_id>
message=<text>
attachments=<photo/video/doc ids>
publish_date=<unixtime>
access_token=<token>
v=<api_version>
Set owner_id to the negative of your community ID (VK's convention: negative IDs are communities, positive IDs are users). Set publish_date to a Unix timestamp in the future, and instead of publishing immediately, VK holds the post and fires it at that timestamp. Leave publish_date off and it posts right away.
To see what you've already queued, the commonly cited approach is calling wall.get with filter=postponed, which returns the postponed queue for that wall. I'll hedge this one: it works as commonly described across third-party docs and mirrors of VK's API reference, but VK's own documentation site has been inconsistently mirrored over the past couple of years, so treat the exact response shape as something to verify against your API version rather than something to hardcode blind.
Editing a postponed post is done the same way you'd edit any wall post, by calling wall.edit with the same post_id and a new publish_date if you want to move the time.
Token types: user vs community vs service
This is the part that trips people up, because VK has three token types with different lifetimes and different implications for scheduling.
User access tokens are tied to a personal VK account and typically expire, historically in the neighborhood of a day for standalone app flows unless you request offline access. If the account owner changes their password or revokes access, every integration using that token breaks at once.
Community (group) access tokens are generated from the community's own management panel (Community settings > API usage > Access tokens) and are scoped to that single community. The practical advantage for scheduling: community tokens don't expire. You generate one, store it, and it keeps working indefinitely unless you explicitly revoke it from the same settings page. For anything you intend to run unattended on a schedule, this is the token type to use.
Service tokens belong to your VK app itself rather than to a user or community, and are meant for app-level calls (some read operations, certain platform-level methods) rather than posting to a specific wall. For wall.post against a specific community, you want the community token, not the service token.
Want to put this into practice? Start a 14-day TimeToPost trial and start scheduling smarter today.
Managing VK alongside other platforms
None of the above changes the fact that VK is still its own island. The delayed-post queue lives in VK's admin panel, your Instagram and X queues live wherever you manage those, and keeping the posting cadence consistent across all of them means checking multiple dashboards.
That's the gap TimeToPost is built to close on the workflow side, even before a direct VK connector exists: build your calendar once (what's going out, on which platforms, at what local time), use the posting-schedule generator to lay out a weekly cadence across every channel you run, and check timing against best-time-to-post data so VK isn't the one platform you post to on gut feeling while everything else is planned. You draft and time the VK post in the same calendar as the rest of your channels, then fire it through the native delayed-post button or the wall.post call above. The goal is one plan, not five separate ones. See the full social media scheduler for how that calendar works across the platforms TimeToPost connects to directly today.
Limits (hedged: most caps here are community-compiled, not official)
VK does not publish a single, authoritative rate-limit and quota page the way some platforms do, so treat these as the numbers that show up consistently across developer communities and third-party references, not as guaranteed contract terms from VK itself.
- Request rate: commonly cited as roughly 3 requests per second for a user token and roughly 20 requests per second for a community token. These numbers are widely repeated but not pinned to an official VK document, so build in backoff logic rather than assuming you can hit the ceiling reliably.
- Delayed post queue size and daily caps: figures like 250 queued delayed posts and 500 posts per day per community circulate in developer forums and scheduler-tool documentation. These are unofficial, community-compiled numbers. I'm flagging them explicitly because they get repeated as fact in places that don't cite a source, and I don't want to do the same thing here without the caveat.
- One external link per post: VK's wall post format generally allows only a single external link attachment per post. If you need to reference more than one URL, put the extras in the post text itself rather than as attachments.
- Character limit: a figure of 16,384 characters for wall posts shows up in multiple places, but like the queue caps above, it isn't something I could confirm against a current, official VK limits document, so hold it loosely and test with your own account before you build automation that assumes it as a hard boundary.
If you're running anything at volume, the safe move is to build your own rate-limit handling defensively (respect HTTP 429s and VK's own error codes for rate limiting) rather than coding to any specific number above.
FAQ
How many delayed posts can a VK community queue? There's a commonly cited cap around 250 queued posts, but this number comes from developer community sources rather than an official VK limits page. Treat it as a practical ceiling to design around, not a guaranteed contract.
Can I edit a delayed post after scheduling it?
Yes. Both the native admin panel and the API (wall.edit with the same post_id) let you change the text, attachments, or the scheduled time before it fires.
Does this work on personal profiles, or only communities? Delayed posting through the admin interface is a community (group/public page) feature. Personal profile walls don't have the same native scheduling button, and posting to a personal wall via the API requires a user token with the account owner's ongoing cooperation, which is a fragile setup for anything automated.
Is it true you can only attach one external link per post? That's the commonly reported behavior for wall posts, one link attachment per post. If you need more than one URL out, put the additional links directly in the post text rather than as separate attachments.