Schedule picked Rush cards
schedule_rush_lineupTurns selected Rush cards into a dated posting lineup and returns a draft automation to review; no post is published until you approve it.
Instructions
Turn Rush cards you have already dealt into a dated plan. This is the only way to get a Rush pick onto a calendar — resolve_rush_item records a verdict but builds nothing, and create_automation invents its own content instead of taking yours.
PUBLISHES NOTHING. It returns a draft automation: no video is rendered and no post exists until publish_automation is called on the id it hands back. That makes this safe to call before showing the user anything.
The whole flow, in order:
get_rush_feed — deal cards.
schedule_rush_lineup — send the ones you want (this tool). Do this BEFORE step 3: if the plan is refused, the deck is left exactly as it was, whereas resolving first would close cards for a run that never existed.
resolve_rush_item with 'keep' for each card you sent, and 'skip' for the rest, to clear the hand.
get_automation — read the lineup back and show the user the dates and copy.
publish_automation — only after the user has explicitly approved. This is irreversible.
Dates are worked out for you: it spreads the items from startDate over postTimes and returns the exact instant each one landed on, so you never compute a timestamp yourself.
ALWAYS PASS timezone. It is the one default that will embarrass you. Omitted, the zone saved on the account is used, and accounts often have none saved — which falls back to UTC, so an evening slot for a user in Asia/Kolkata is planned at half past one in the morning. Pass the user's IANA zone every time unless they actually want UTC.
startDate defaults to tomorrow, which is usually right. postTimes defaults to a spread that fits the items into the days available; it is a reasonable shape but it knows nothing about when this audience is awake, so prefer the times the workspace already posts at — list_posts shows the existing cadence. Note the plan-window check is on startDate only, so a long run can still spread past the date the plan is paid through.
Refusals worth knowing before you call: a lineup may hold at most 200 items; postTimes cannot be longer than the plan's reels-per-day (read reelsPerDay from whoami); and a run cannot start after the date the plan is paid through, so check periodEnd in whoami if the user wants something far out.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Label for the run. Defaults to a dated one. | |
| items | Yes | The picked cards, in the order you want them posted. | |
| timezone | No | IANA zone the postTimes are read in, e.g. 'Asia/Kolkata'. Send it. A zone saved on the account takes precedence (so a trip cannot silently re-time somebody's calendar), but when none is saved this is all there is, and omitting it means UTC. | |
| postTimes | No | Times of day, HH:MM, applied to every day of the run. Deduplicated and sorted. Defaults to a spread that fits. | |
| startDate | No | First day, YYYY-MM-DD, in the account's scheduling zone. Defaults to tomorrow. | |
| accountIds | Yes | Connected account ids from list_connected_accounts. Every item is published to all of them. Required here even though the plan itself would accept none, because a lineup with no accounts cannot be published and there is nothing useful to do with it. | |
| workspaceId | No | Workspace to act in. Defaults to the active one. |