Scheduling posts

Posting windows#

Each selected window adds one scheduled post per day per account, provided approved posts and an available worker are ready. Windows follow each assigned worker's local timezone, not the caller's timezone or UTC.

Replace the complete windows array when enabling or disabling slots. Use 1–4 sorted HH:mm starts, each at least 3 hours apart, from 08:00 through 17:00 inclusive. The four standard dashboard slots are shown above; the shared validator also accepts other starts that meet these constraints.

Defaults and overrides#

The account override takes precedence over the company default. If neither is set, global posting-window and gap rules apply, including the legacy company postsPerDay setting. The new schedule controls cadence through window count; it does not require a separate postsPerDay field.

Company changes apply only to accounts that inherit the default. Individual account schedules still take priority even if you edit the company default afterward, through the dashboard, API, or MCP. Clearing an account override makes it use the current company default, including any changes made since the override was created. Company scope always means the API key's company, never all companies.

Send schedule: null to clear an account override and inherit the company default. Clearing the company schedule restores global rules for inheriting accounts. An empty windows array is invalid. Clearing a schedule does not pause posting.

In the dashboard, use Accounts → Posting schedule to change the company default. Open an individual account and use its Posting schedule card to override it. Clear schedule followed by Save schedule restores inheritance.

Scheduling with the API#

Read schedules with accounts:read and update them with accounts:write. Account IDs must belong to the API key's company. Reads return source (account, company, or global), scheduledPostsPerDay (null for global rules), and maxPostsPerDay. Account reads also return the company default, effective schedule, and resolved timezone; before worker assignment the reported timezone is a fallback.

# Read the company default
curl "https://us-central1-clickbaitcarousel.cloudfunctions.net/publishingApi/v2/schedule" \
  -H "Authorization: Bearer $HUMANPOST_API_KEY"

# Two daily windows for accounts using the company default
curl -X PATCH "https://us-central1-clickbaitcarousel.cloudfunctions.net/publishingApi/v2/schedule" \
  -H "Authorization: Bearer $HUMANPOST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"schedule":{"windows":["08:00","17:00"]}}'

# Override one account with a single midday window
curl -X PATCH "https://us-central1-clickbaitcarousel.cloudfunctions.net/publishingApi/v2/accounts/ACCOUNT_ID/schedule" \
  -H "Authorization: Bearer $HUMANPOST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"schedule":{"windows":["11:00"]}}'

# Restore company inheritance for that account
curl -X PATCH "https://us-central1-clickbaitcarousel.cloudfunctions.net/publishingApi/v2/accounts/ACCOUNT_ID/schedule" \
  -H "Authorization: Bearer $HUMANPOST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"schedule":null}'

# Verify the effective schedule and its source
curl "https://us-central1-clickbaitcarousel.cloudfunctions.net/publishingApi/v2/accounts/ACCOUNT_ID/schedule" \
  -H "Authorization: Bearer $HUMANPOST_API_KEY"

Scheduling with MCP#

Use the same schedule payload and inheritance rules through these tools.

get_company_schedule({})
update_company_schedule({"schedule":{"windows":["08:00","17:00"]}})
get_account_schedule({"accountId":"ACCOUNT_ID"})
update_account_schedule({"accountId":"ACCOUNT_ID","schedule":{"windows":["11:00"]}})
// Clear the override to inherit the company default again
update_account_schedule({"accountId":"ACCOUNT_ID","schedule":null})

Dispatch and missed posts#

Changes affect future dispatches and do not move or cancel tasks already released to workers. Posting windows are delivery windows, not exact publication times. Queue posts as usual with create_post / POST /v2/posts or queue_post / POST /v2/posts/{postId}/queue.

Missed posts may catch up or use unused windows as make-up slots. Four posts per account per worker-local day remains the hard maximum, including make-up posts. Selecting fewer slots sets the normal cadence, not an absolute cap on make-up posts.