Example: a post every week

You have a post wired to your accounts, and you want it to go out every Tuesday and Friday morning rather than right now. Scheduling is two steps: publish the workflow's definition, then arm the trigger.

You need: an AI client connected to Papera and a workflow with a post, its accounts, and a trigger wired to the post. Steps 1 to 5 of one post, every account build exactly that.

The ids below are shortened for readability.

1. Publish the definition

A schedule fires server-side against a saved snapshot of the workflow, not against whatever the draft happens to be at that moment. So the workflow has to be published first.

// publish_workflow
{ "project_id": "9c1f2a84", "workflow_id": "41ac7d20" }

This returns a plan and a token. The plan tells you what the snapshot will contain. Nothing is posted by this tool, now or later: it only records the definition a schedule can run.

// publish_workflow
{ "project_id": "9c1f2a84", "workflow_id": "41ac7d20", "confirm_token": "ct_2f10..." }

2. Arm the trigger

You: Post it every Tuesday and Friday at 9am Berlin time, starting next Tuesday.

// arm_schedule
{
  "project_id": "9c1f2a84",
  "workflow_id": "41ac7d20",
  "trigger_id": "trigger-c3",
  "fire_at": "2026-08-25T07:00:00Z",
  "recurrence": {
    "kind": "weekly",
    "timeOfDay": "09:00",
    "daysOfWeek": [2, 5],
    "timeZone": "Europe/Berlin"
  }
}

daysOfWeek counts from Sunday as 0, so [2, 5] is Tuesday and Friday. timeOfDay is a wall-clock time in the timezone you name, which means 9am stays 9am across a clock change. fire_at is the first fire, in ISO 8601.

Papera returns the plan in words before arming anything:

Papera: Arms trigger trigger-c3. First fire 25 August 2026 at 09:00, then weekly on Tuesday and Friday at 09:00 (Europe/Berlin).

Check the day and the timezone, then confirm:

// arm_schedule
{
  "project_id": "9c1f2a84",
  "workflow_id": "41ac7d20",
  "trigger_id": "trigger-c3",
  "fire_at": "2026-08-25T07:00:00Z",
  "recurrence": {
    "kind": "weekly",
    "timeOfDay": "09:00",
    "daysOfWeek": [2, 5],
    "timeZone": "Europe/Berlin"
  },
  "confirm_token": "ct_9ab3..."
}

If the workflow was not published, arm_schedule refuses here and tells you to run publish_workflow first.

3. Check what went out

After a fire, the outcome is recorded per account, exactly as it is for a manual publish:

// get_publish_status
{ "project_id": "9c1f2a84" }

Each row names the account, whether it published or failed, and the link to the live post on success.

4. Turn it off

// disarm_schedule
{ "project_id": "9c1f2a84", "workflow_id": "41ac7d20", "trigger_id": "trigger-c3" }

Confirm with the returned token, and the trigger stops firing. Posts that already went out are unaffected, and you can arm it again at any time.

Other cadences

An interval cannot be tighter than five minutes.

If you change the workflow later

A schedule runs against the snapshot, so edits to the draft do not reach it until you publish again. Two things to keep in mind:

• Run publish_workflow again after an edit you want the schedule to pick up.
• Publishing replaces the snapshot, and any armed schedule whose trigger is no longer in the draft stops. Deleting a trigger cancels its schedule.