Schedules, Webhooks, and Triggers

Every assignment can always be run manually with Run now. On top of that, the Schedule section offers two standing triggers you can enable independently: a schedule and a webhook.

The choice of trigger is a choice about what drives the work. A schedule suits work driven by the calendar — the report is due Monday whether or not anything changed. A webhook suits work driven by events — there is nothing to do until a ticket arrives, and then the work should start immediately. Because the two standing triggers are independent, an assignment can also carry both: a nightly sweep on a schedule, plus a webhook for items that should not wait until night.

Schedules

Choose a frequency and the editor adapts:

Frequency	You choose
One-time	A date and time — or leave the date empty to run immediately when created.
Hourly	Every N hours, at a given minute.
Daily	A time of day.
Weekly	One or more days of the week, and a time.
Monthly	A day of the month (or “last day of month”), and a time.
Custom	Repeat every N hours, days, weeks, or months — with day pickers for weekly and monthly cadences.

Recurring schedules run in a timezone you pick; it defaults to your browser’s. There is no cron syntax to learn — the builder covers the cadences, and the custom option handles the in-between ones (“every 2 weeks on Tuesday”).

A few schedules and the jobs they fit:

• Weekly, Mondays 6:00 AM, America/New_York — a pipeline report ready before the East Coast standup.
• Daily, 7:30 AM — an overnight-activity digest waiting with the first coffee.
• Hourly, every 4 hours at minute 15 — a periodic sweep of a queue that doesn’t need continuous watching.
• Monthly, last day of month, 5:00 PM — a close-out summary that lands on the true month end, however long the month runs.
• Custom, every 2 weeks on Tuesday — prep notes timed to a two-week sprint.
• One-time, a specific date next quarter — a job that should run exactly once, on the day you picked.

Schedule in the audience’s timezone

Pick the timezone of the people who will read the output, not of whoever creates the assignment. A “Monday 6:00 AM” report scheduled in the wrong zone arrives mid-afternoon for the team it was meant to greet.

Webhooks

Enable Run via webhook and choose a path, and the assignment gets a URL other systems can POST to:

https://workprentice.ai/api/v1/hooks/<workspace-id>/<your-path>

• Authentication — attach a workspace API key from the dropdown; callers then present it in the X-API-Key header. A webhook without a key accepts unauthenticated calls, so attach one unless you have a reason not to. Keys are created in Settings → Workspace → API Keys; see API keys and webhooks.
• Payload — the JSON body of the POST is handed to the run as its webhook payload, so instructions can refer to it (“enrich the ticket in the payload”).
• Dry runs — add ?run_type=dry_run while testing: the agent works, but writes to external systems are blocked.
• Response — a successful trigger returns the started session’s id, so the caller can link straight to the run.

A dry-run test call from a ticketing system looks like this:

curl -X POST \
  "https://workprentice.ai/api/v1/hooks/<workspace-id>/ticketing/new-ticket?run_type=dry_run" \
  -H "X-API-Key: wak_..." \
  -H "Content-Type: application/json" \
  -d '{"ticket_id": "12345", "subject": "Cannot log in"}'

The response names the session that started, so the calling system can record a link to the run:

{ "session_id": "…", "run_type": "dry_run" }

Once the rehearsal looks right, drop the run_type parameter and point the real system at the URL. Callers get clean signals when something is off: a paused assignment returns 403, an unknown path 404, and a bad key 401. The webhook guide walks this end to end, including creating and storing the API key.

Which trigger for which job

• A report every Monday: weekly schedule. Calendar-driven work belongs on a schedule; the value is that it arrives without anyone asking.
• Work that reacts to another system — new ticket, form submission, deploy: webhook. The event carries its own payload, and the run starts the moment it happens instead of at the next scheduled sweep.
• A job you’re still iterating on: no standing trigger at all — save it On-Demand and use Run now until the instructions are right. A half-finished assignment on a schedule produces half-finished output on a schedule, so add the trigger last.