Queue a post for Threads through the same call you use for every other network, with Threads's real rules checked before it is queued rather than at the moment it fires.
Send the post with a scheduledAt and it is queued. Credits are spent when it publishes, not when you schedule it, so a queue you never fire costs nothing.
curl -X POST https://api.postlake.dev/v1/posts \
-H "Authorization: Bearer $POSTLAKE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "Ready when you are",
"accounts": ["acc_…"],
"scheduledAt": "2026-09-01T07:00:00",
"timezone": "Europe/London"
}'That fires at 7am London, through the clock change, because the zone travels with the post instead of being flattened into UTC by whoever wrote the integration. Sending a local time with a trailing Z is the single most common scheduling bug there is: the post goes out an hour off for half the year.
These come from the same registry the publish path validates against, so nothing here can promise something the API would refuse.
| Caption limit | 500 characters |
| Media | text alone is fine, up to 20 images, 1 video, video up to 5 minutes |
| Daily limit | 250 posts a day |
| Publishing | Synchronous. The result is known when the call returns. |
| Editing a queued post | Yes, until it fires |
| Cancelling | Yes, until it fires |
Threads-specific settings you can send with a scheduled post: replyControl, topicTag.
A queued post that turns out to be invalid is the worst failure a scheduler has, because nobody is watching when it happens. So the same checks that run on a live publish run when you queue it: media rules, caption length, the network's own option values, and whether the connection is still alive. A post Threads would refuse comes back as an error now, with the field at fault and the fix, rather than as silence tomorrow morning.
If it does fail at fire time, for something only Threads could know, the failure reaches you by webhook and in the daily summary, and nothing is charged for it.
Yes. Send a scheduledAt with the post and PostLake queues it, then publishes it at that moment. You can edit or cancel it at any point before it fires, and you are only charged when it actually publishes.
Pass timezone as an IANA name alongside a naive scheduledAt, for example Europe/London with 2026-09-01T07:00:00. The stored fire time is UTC, but the zone is kept so the post survives a clock change and lists show the local time you meant.
Threads allows around 250 posts a day. PostLake tells you the limit through GET /v1/platforms rather than making you find out by being refused.
Yes. Over the hosted MCP server it is the create_post tool with the same scheduledAt. The agent authorises with OAuth, so no API key is pasted into a chat, and you can cap what it may do: which brands, which networks, and how much in a day.