Reschedule Post
Move a scheduled post to a new time or the next open slot. Requires a paid Creator or Lifetime plan.
POST /v1/queue/{scheduleId}/reschedule moves an already-scheduled post to a different time without cancelling and re-creating it. publish_at takes an ISO-8601 timestamp or the literal 'next-slot', and timezone is a required IANA zone in both cases.
Unlike the schedule route, timezone is mandatory here even for 'next-slot', because slot resolution is done in the user's local grid and there is no 'now' shortcut to fall back on.
Example request
Authenticate with a bearer token in the Authorization header. Create a key on the API page in your LinkedMash settings and export it as LINKEDMASH_API_KEY before running this.
curl -X POST "https://api.linkedmash.com/v1/queue/sch_3a9f81d2/reschedule" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"publish_at": "2026-08-12T08:30:00",
"timezone": "Europe/Berlin"
}'Path parameters
The id of the scheduled entry to reschedule.
Header parameters
Your secret API key as a Bearer token.
Body parameters
An ISO-8601 timestamp or 'next-slot'.
IANA timezone for the new time.
Response
{
"status": true,
"data": {
"ok": true,
"newRunAtUTC": "2026-06-26T08:30:00.000Z"
}
}Response fields
Every response is wrapped in the same envelope: a status flag and a data payload, with meta present where there is pagination or a plan limit to report.
true on success. Every LinkedMash API response carries this envelope flag alongside data, so a client can branch on it without re-reading the HTTP status.
true when the entry was moved.
The new publish moment in UTC. Read it back when you sent next-slot, since that is the only place the chosen time appears.
Moving a post without recreating it
Rescheduling keeps the queue entry, which is why it is preferable to cancel-and-reschedule.
Get the scheduleId
From GET /v1/queue, or from the response of the original schedule call if you stored it.
Send both fields
publish_at and timezone are both required, including when publish_at is 'next-slot'. Omitting either returns 400 and nothing moves.
Read back the new time
data.newRunAtUTC is the resolved publish moment. With 'next-slot' it is the only way to learn which slot you got.
The id survives the move
The same scheduleId still cancels or reschedules the entry afterwards, so anything you have stored against it stays valid.
Behaviour and limits
Requires a Creator or Lifetime plan
Everything under /v1/posts, /v1/queue, /v1/schedule, /v1/media and /v1/analytics sits behind one middleware that checks for an unlocked Studio, so a Reader-plan or free key gets 402 with code SUBSCRIPTION_REQUIRED before the handler runs. Bookmark and label reads are on a separate router and are not affected by this gate.
Both publish_at and timezone are required
Omitting either returns 400 "publish_at and timezone are required." before anything is moved.
'next-slot' needs a configured schedule
If the grid yields no free slot the call returns 400 "No free posting slot available." rather than leaving the post at its old time and reporting success.
The scheduleId is stable across a reschedule
Moving a post keeps its queue entry, so the same scheduleId still cancels or reschedules it afterwards.
Errors
Failures carry the same envelope as a success, with the reason in message and a stable machine-readable code where the status alone is ambiguous — several distinct conditions share a 402.