Auto Schedule API

Trigger a capture now

The one endpoint an API key can reach on this host. It starts an immediate capture of a page you already have scheduled — or tells you one was already running.

The endpoint

POSThttps://autoapi.websitescreenshotworld.com/auto-schedule/v1/web-pages/{webPageId}/trigger-now

Field	Type	Default	Description
`webPageId`Required	uuid (path)	—	The scheduled page to capture. It must belong to the key’s own account. Anything that is not a UUID answers web_page_id_invalid rather than a 404.
`X-Api-Key`Required	string (header)	—	Your API key. The only credential this endpoint accepts.

No body, no query parameters

There is nothing to send. A body, if you send one, is ignored — and if you were looking for a place to override the format or the viewport, that is the Instant Snap API, not this one.

Making the call

curl -X POST \
  https://autoapi.websitescreenshotworld.com/auto-schedule/v1/web-pages/8f14e45f-ceea-467a-9d0b-2c0b6f1a9e77/trigger-now \
  -H "X-Api-Key: $WSW_API_KEY"

Two success answers

Both outcomes are 200 with "success": true, told apart by status. This distinction is the point of the endpoint’s shape: an earlier version could not express “nothing new was started”, and callers retried into a capture that was already running.

status: triggered

{
  "success": true,
  "status": "triggered",
  "web_page_id": "8f14e45f-ceea-467a-9d0b-2c0b6f1a9e77",
  "triggered_by": "api",
  "triggered_at": "2026-09-01T09:14:22.000Z",
  "message": "A capture has been started."
}

A capture was started. This consumed a slot of the per-minute window and recorded one API request against your account.

status: already_pending

{
  "success": true,
  "status": "already_pending",
  "web_page_id": "8f14e45f-ceea-467a-9d0b-2c0b6f1a9e77",
  "triggered_by": "ui",
  "triggered_at": "2026-09-01T09:13:51.000Z",
  "message": "A capture is already pending for this web page."
}

The page already had a capture pending — started from the dashboard (triggered_by: ui) or by an earlier call (triggered_by: api). Nothing new was started, no slot was consumed, and no quota was charged.

already_pending means stop, not retry

triggered_at on this answer is the time of the original enable, not of your call — which is how you can tell how long the running capture has been going. The right reaction is to wait for it, never to trigger again.

Response fields

Field	Type	Default	Description
`success`	boolean	—	Always true here — both outcomes are successes.
`status`	string	—	triggered or already_pending. The field to branch on.
`web_page_id`	uuid	—	The page the capture was requested for.
`triggered_by`	string	—	Who put the page into its pending state: ui for the dashboard, api for an API key.
`triggered_at`	string (ISO 8601, UTC, milliseconds)	—	When the pending capture was enabled. For already_pending this is the original enable, not this call.
`message`	string	—	One sentence explaining the outcome, safe to show to an end user. Its wording is not part of the contract.

What the capture uses

Everything comes from the schedule, exactly as its next scheduled run would have used it:

The schedule’s URL
Its Web Profile in full — device, resolution, format, blocking, locale, headers, watermark and the rest
Its cloud storage destination and its retention
Its notification settings

The capture is recorded with its trigger source set to the API — it is labelled QUICK CAPTURE API in the capture viewer — so you can tell API-triggered captures apart from scheduled ones.

Sitemap schedules cannot be triggered

A sitemap schedule runs only on its schedule: a run captures up to 1,000 pages over hours, paced to the proxy capacity. Triggering one answers 409 sitemap_schedule_not_triggerable and spends nothing. To run one now, create it with Start set to Immediately.

The schedule is not moved

A trigger is an extra capture

The next scheduled run happens exactly when it was always going to. Triggering at 09:14 does not reset a daily schedule to fire at 09:14 tomorrow, and it does not skip the run that was already due.

That also means a trigger and a scheduled run can land close together. If you trigger after every deploy on a page that is also captured hourly, expect both.

Paused and stopped schedules

A paused schedule still triggers

The endpoint does not check whether the schedule is running. Pausing stops the timetable; it does not close this door. A trigger against a paused schedule succeeds, produces a capture and spends quota.

If a pipeline should stop triggering when a schedule is paused, that condition belongs in your pipeline — pausing in the application will not enforce it for you.

Seeing the result

The response tells you the trigger was accepted, not what the capture produced. The capture runs asynchronously and appears in the application’s capture list for that schedule when it finishes, and lands in the schedule’s storage destination.

There is no endpoint on this API for reading the capture back.
If your workflow needs the file in hand at the end of the request, use the Instant Snap API instead — it returns the capture rather than a receipt.
A webhook tells your systems when the triggered capture has finished; the Web Profile’s capture email tells a person.

Did this page answer your question?

Tell us what is missing