Set Posting Schedule
Replace your recurring posting schedule grid. Requires a paid Creator or Lifetime plan.
PUT /v1/schedule replaces the recurring posting schedule. Both timezone (an IANA name, as a string) and grid (an array) are required, and the write is a full replacement — the stored schedule becomes exactly what you send.
Each grid entry is a repeating slot: a wall-clock time plus the weekdays it applies to, for example { time: "8:30 am", days: { Mon: true, Wed: true, Fri: true } }. Together they define every candidate publishing time for 'next-slot' scheduling.
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 PUT "https://api.linkedmash.com/v1/schedule" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"timezone": "America/New_York",
"grid": [
{
"time": "8:30 am",
"days": {
"Mon": true,
"Wed": true,
"Fri": true
}
}
]
}'Header parameters
Your secret API key as a Bearer token.
Body parameters
IANA timezone for the schedule.
The schedule grid as [{ time, days }].
Response
{
"status": true,
"data": {
"timezone": "America/New_York",
"grid": [
{
"time": "8:30 am",
"days": {
"Mon": true,
"Wed": true,
"Fri": true
}
}
]
}
}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.
The stored IANA zone, echoed back after the write.
The stored slots. This is the whole schedule as it now stands — PUT replaces rather than merges, so anything absent here was deleted.
Wall-clock time in the stored timezone.
Weekday flags for that slot.
Changing a posting schedule safely
This is a replace, so the risk is deleting slots you meant to keep.
Fetch the current grid
GET /v1/schedule first, always. There is no partial update and no merge — whatever you send becomes the entire schedule.
Modify the array locally
Append, edit or drop entries in your own copy, keeping the ones you are not changing.
Send timezone and grid together
Both are required. timezone must be a non-empty string and grid must be an array; the contents of each entry are not validated, so a malformed time is stored and simply never resolves to a slot.
Re-check the resolved slots
Call GET /v1/queue/slots afterwards. If it returns nothing, the grid is not producing usable times regardless of what the write returned.
Remember existing entries do not move
Posts already in the queue hold their own resolved timestamps. Changing the grid affects future slot resolution only.
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.
PUT means replace, not merge
Sending a one-entry grid deletes every other slot. Read GET /v1/schedule, append, and send the whole array back if you are adding to an existing schedule.
Validation is shallow by design
timezone must be a non-empty string and grid must be an array — both are checked before the write. The contents of each grid entry are not validated here, so a malformed time silently produces a slot that never resolves.
Changing the timezone reinterprets every slot
The grid stores wall-clock times, so moving the schedule from Europe/Berlin to America/New_York shifts every existing slot by the offset rather than keeping the same absolute times.
Already-scheduled posts do not move
Existing queue entries hold their own resolved timestamps. Editing the grid changes future slot resolution only; use the reschedule route to move something already queued.
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.