Get Posting Slots
Get the next available posting slots from your schedule. Requires a paid Creator or Lifetime plan.
GET /v1/queue/slots computes the next free posting times from the account's recurring schedule grid and returns them as concrete timestamps. count controls how many to return, and timezone is the IANA zone the times are expressed in.
It is the endpoint to call before scheduling if you want to show a user their options, or to pick a specific slot rather than letting POST /v1/posts/{id}/schedule resolve 'next-slot' for you.
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/queue/slots?count=5&timezone=Europe%2FBerlin" \
-H "Authorization: Bearer $LINKEDMASH_API_KEY"Header parameters
Your secret API key as a Bearer token.
Query parameters
Combine these parameters to narrow your results.
Number of upcoming slots to return.
IANA timezone for the returned slot times.
Response
{
"status": true,
"data": [
{
"day": "Mon",
"time": "8:30 am",
"date": "2026-06-22",
"displayDate": "Mon, Jun 22"
},
{
"day": "Wed",
"time": "8:30 am",
"date": "2026-06-24",
"displayDate": "Wed, Jun 24"
}
]
}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 next free slots, resolved from the schedule grid. Slots already holding a scheduled post are skipped, so this list shrinks as you fill the queue.
Weekday name for the slot.
Local time of the slot, in the requested timezone.
The concrete ISO date the slot falls on. Pass this back as publish_at to take a specific slot instead of letting next-slot choose.
Pre-formatted label for showing the slot in a UI.
Letting a user pick a time
Reading slots first turns scheduling from a guess into a choice.
Confirm a schedule exists
GET /v1/schedule and check that grid is non-empty. An empty grid means this route returns nothing and next-slot scheduling will fail with 400 — prompt the user to configure one instead.
Request slots in their timezone
Pass count and an IANA timezone. The times come back in that zone, so they can be shown without any conversion on your side.
Schedule against a specific date
Take the date from the slot the user picked and send it as publish_at. That is what distinguishes picking a slot from letting the system pick one.
Re-read after each booking
Taken slots are excluded from this list, so scheduling into one changes the answer. Re-fetch between bookings rather than reusing a stale array.
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.
Slots come from the schedule grid, not from thin air
The grid set by PUT /v1/schedule is the only source. An account with an empty grid gets an empty array, which is also why 'next-slot' scheduling fails with 400 on such an account.
Already-taken slots are skipped
The response is the next FREE slots — times that already hold a scheduled post are not returned, so two consecutive calls with count: 1 give the same answer until you actually schedule something.
'next-slot' calls this route internally
POST /v1/posts/{id}/schedule with publish_at: 'next-slot' asks this same route for one slot and uses its date. Reading it yourself first is how you learn the time before committing.
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.