Cronvoy API

v1 · August 13, 2026

Everything the dashboard does, your code can do: launch a browser run, put one on a schedule, set up a job-application agent, read back what it did. Point an AI assistant at it and it can operate Cronvoy on your behalf.

Authentication

Create a key in the dashboard under Settings → API keys. It is shown once. Send it as a bearer token:

curl https://cronvoy.com/api/v1/status \
  -H "Authorization: Bearer cv_live_..."

A key acts as your account and nothing more. Every request is carried out as you against the same database rules your dashboard obeys, so a key can never read or touch another account's data. What a given key may do on your account is decided by the scopes you ticked when you made it:

Quickstart

Launch a cloud run and watch it:

curl -X POST https://cronvoy.com/api/v1/runs \
  -H "Authorization: Bearer $CRONVOY_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Go to news.ycombinator.com and list the top 3 stories"}'

# { "queueId": "…", "target": "cloud", "status": "queued", … }

curl "https://cronvoy.com/api/v1/live" -H "Authorization: Bearer $CRONVOY_KEY"
# { "active": true, "status": "running", "action": "reading the page", "stepNo": 4, "log": [ … ] }

Runs

Schedules

A schedule is a prompt plus a cadence. Cloud schedules fire on our servers around the clock; extension schedules fire in your Chrome.

curl -X POST https://cronvoy.com/api/v1/schedules \
  -H "Authorization: Bearer $CRONVOY_KEY" -H "Content-Type: application/json" \
  -d '{
    "prompt": "Check my Loops dashboard for a draft campaign and tell me if one is ready",
    "every": "daily",
    "at": "06:30",
    "tz": "America/New_York",
    "target": "cloud"
  }'

every takes "hourly", "6h", "daily", "weekly", or a number of minutes (60 minimum). at is the local anchor time: an interval schedule is phase-locked to it, so two agents can be set an hour apart and alternate forever. For specific weekdays send days instead: {"days":["mon","wed","fri"],"at":"09:00"} — names or numbers, 0 (Sunday) to 6.

Agents

An agent is a preset with settings it carries into every run — the job-application agent knows your titles, salary, work authorization and EEO answers, and shares one record ledger across all your agents so it never applies to the same job twice.

# what you can create, and every setting it takes
curl https://cronvoy.com/api/v1/agent-templates -H "Authorization: Bearer $CRONVOY_KEY"

# create one
curl -X POST https://cronvoy.com/api/v1/agents \
  -H "Authorization: Bearer $CRONVOY_KEY" -H "Content-Type: application/json" \
  -d '{
    "templateId": "job-apply",
    "name": "Product Manager Job Agent",
    "settings": {
      "titles": ["Product Manager", "Senior Product Manager"],
      "locations": "Remote (US)",
      "yearsExperience": "8",
      "workAuth": "US citizen",
      "perRun": 3
    }
  }'

The response lists missingRequired if anything the forms will ask for is still blank. Then read what it did:

curl "https://cronvoy.com/api/v1/agents/{id}/records?status=applied&limit=20" \
  -H "Authorization: Bearer $CRONVOY_KEY"

Profiles

A profile is the identity a run wears: its own logins, its own browser session, its own documents. Use separate profiles to keep two accounts on the same site from mixing.

Recipes

Set up a job agent and let it run every morning

POST /api/v1/profiles     { "name": "Job hunt" }                        → profileId
POST /api/v1/profiles/{profileId}/documents  { name: "resume.pdf", … }
POST /api/v1/agents       { "templateId": "job-apply", "settings": {…} } → agentId
POST /api/v1/schedules    { "prompt": "Apply to product roles that fit me",
                            "agentId": "…", "profileId": "…",
                            "every": "daily", "at": "08:00", "tz": "America/New_York" }

Pause everything

GET   /api/v1/schedules
PATCH /api/v1/schedules/{id}   { "enabled": false }     # for each

Did last night's run get anywhere?

GET /api/v1/runs?limit=1
GET /api/v1/runs/{id}?transcript=0     # status, summary, and a diagnostics block

Limits

• 120 requests a minute per key.
• Run budgets per key, per day and per month (a new key starts at 50/day, 500/month). GET /api/v1/status always reports what's left. A run costs real browser time and model tokens, which is why launching is budgeted and reading is not.
• Every run launched with a key records which key launched it, so revoking one has a visible blast radius.

Errors

Errors are JSON, with a stable error code to branch on and a message to read:

{ "error": "missing_scope", "message": "This API key does not have the `runs:write` scope.",
  "needed": "runs:write", "has": ["runs:read"] }

Questions or something missing: hello@cronvoy.com.