Schedules

A schedule is a scrape that runs on its own. This is the shape most production use looks like: a daily pull whose results you expect to be there.

curl -X POST 'https://api.helicitylabs.com/schedules' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "label": "daily order pull",
    "request": {
      "url": "https://example.com/orders",
      "render_js": true,
      "proxy_type": "premium"
    }
  }'

The request is an ordinary /scrape body — every field from Scraping applies.

Managing one

Call	What it does
`GET /schedules`	List them
`GET /schedules/{id}`	One schedule
`PATCH /schedules/{id}`	Change cadence or request
`POST /schedules/{id}/pause`	Stop running it
`POST /schedules/{id}/resume`	Start again
`POST /schedules/{id}/run-now`	Fire once, off-cadence
`DELETE /schedules/{id}`	Remove it

run-now is the fastest way to check a schedule does what you meant without waiting for its next slot. It records a normal run, so the result shows up in the history like any other.

Runs and results

Every execution is a run you can inspect:

curl 'https://api.helicitylabs.com/schedules/{id}/runs' \
  -H 'Authorization: Bearer YOUR_TOKEN'

GET /schedules/{id}/runs/{run_id} is one run, and GET /schedules/{id}/runs/{run_id}/result is its output.

That history is what makes a failure legible after the fact: each run carries its own ok, error_class and timing, so “when did this start returning nothing” is a query rather than an investigation.

Pagination

Schedules can page through a listing rather than fetching one URL. Pass a pagination block on the schedule; the run follows the pages and the result covers all of them.

Schedules run on separate infrastructure from on-demand scrapes, so a burst of interactive traffic does not delay them, and a slow schedule does not eat your interactive capacity. They draw on the same credit balance.