Get Posting Schedule
Get your recurring posting schedule grid. Requires a paid Creator or Lifetime plan.
GET /v1/schedule returns the recurring posting schedule: an IANA timezone and a grid of repeating time slots, each with the weekdays it applies to. This grid is what /v1/queue/slots turns into concrete timestamps and what 'next-slot' scheduling resolves against.
An account that has never set a schedule gets a default of { timezone: "UTC", grid: [] } rather than a 404, so you can read this safely before deciding whether to prompt a user to configure one.
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 "https://api.linkedmash.com/v1/schedule" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY"Header parameters
Your secret API key as a Bearer token.
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.
IANA zone the grid times are interpreted in. Defaults to UTC for an account that has never configured a schedule.
The repeating slots. An empty array is the signal that next-slot scheduling will fail with 400.
Wall-clock time such as "8:30 am", in the schedule timezone, so it follows daylight saving rather than drifting.
Weekday flags, e.g. { "Mon": true, "Wed": true }. Only days set to true are candidate slots.
Checking a schedule before you rely on it
Almost every scheduling failure traces back to a grid nobody configured.
Read before offering slot scheduling
An account that has never set a schedule returns { timezone: "UTC", grid: [] }. Offering next-slot scheduling on that account produces a 400 the user cannot interpret.
Show the timezone alongside the times
Grid times are wall-clock in the stored zone. Displaying "8:30 am" without saying which zone is how a user ends up posting at 2am.
Read before you write
PUT /v1/schedule replaces the whole object. Adding one slot means fetching this, appending, and sending the full grid back.
Resolve to real times when it matters
The grid is a recurring pattern, not a list of dates. GET /v1/queue/slots is what turns it into concrete timestamps.
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.
An empty grid is the meaningful signal
grid: [] means 'next-slot' scheduling will fail with 400. Check for it before offering slot-based scheduling in a UI.
Times are wall-clock, in the stored timezone
Grid entries look like { time: "8:30 am", days: { Mon: true, Wed: true } }. They are local times in the schedule's timezone, not UTC, so they follow daylight saving.
Read before you write
PUT /v1/schedule replaces the whole object. Fetch here first if you intend to add a slot rather than redefine the week.
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.