Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

Apply with AI

Auto-apply: Apply with AI fills and sends employer applications for you by default (resume required). Use hosted apply for Worklittle-published jobs.

Auto-apply on Worklittle means the session opens the employer's own form, fills it from the candidate resume, and submits. API keys always submit. Hosted apply is a different path: it posts JSON to a Worklittle-published job.

Two apply paths, one decision

| Path | Use when | Endpoint | Cost |
| --- | --- | --- | --- |
| **Hosted apply** | The employer published the role on Worklittle and you have the form schema | `POST /jobs/:id/apply`, MCP `submit_job_application` | $0.01 per successful submit |
| **Apply with AI** | The role lives on the employer's own site and `can_apply` is `true` | `POST /jobs/apply`, MCP `apply_for_job` | AI token usage at published rates. Typical successful session ~$0.01–$0.03. No per-user concurrent cap; excess starts `queued` (Waiting) when the **200** global Browser Run slots are full |
| **Public board apply** | You built a careers site on the employer's board and want no API key | `POST /business/jobs/company/:company/jobs/:id/apply` | Free, IP rate limited |

The decision is made by data, not by guesswork. Hosted apply returns 404 for index-only listings. Apply with AI runs only where the eligibility flag says it can. Start from Apply for jobs. Hosted board forms: Embedded job board.

can_apply is the only check

GET /jobs and GET /jobs/:id both return a boolean can_apply. That field is the only supported way to know whether a session can run. Over 4 million open listings currently return true.

Do not infer eligibility from source_name, from the shape of apply_url, or from the employer careers URL. Worklittle already accounts for which forms it can fill and submit, plus per-job history and board-level cooldowns, when it computes the flag. Guessing from the URL yourself will start sessions that immediately fail and still bill you.

curl -s "https://api.worklittle.com/jobs?q=software+engineer&limit=10" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY" \
  | jq '.data[] | select(.can_apply == true) | {id, title}'

Behind that boolean sits a denylist that protects both sides. When a job's form repeatedly turns into a bot or spam handoff, that job is denied permanently. When enough jobs on the same board behave that way, the whole board goes into a temporary cooldown. Neither is something you can override from the client, and both are separate from a job simply being closed. More detail: Closed jobs and eligibility.

Cost model

Apply with AI is not a flat POST fee. It bills AI token usage at published rates for field fill, on-session resume generation, essays, and related turns. See Jobs pricing.

Spend debits the key owner's Personal organization and shows as AI job apply on Usage. Observed successful sessions typically land around $0.01–$0.03 (about 1–3¢). Close or stop_apply_for_job sessions you will not finish. If the Personal org has Worklittle Instant ($20/mo AI credit), that credit alone covers on the order of up to ~2,000 typical Apply with AI sessions per Instant period before PAYG, assuming most of the credit goes to applies.

There is no per-account concurrent cap. Credit and Instant gate spend. Worklittle holds up to 200 global Browser Run slots at once. When those slots are full, the session is queued (Waiting) until a slot frees.

Architecture of a session

Apply with AI is full automation for eligible employer forms: start a session, it fills the form, and it submits. On worklittle.com the same run shows a cloud browser in chat so the person can watch. Poll for completion. API keys always submit.

1. Start. POST /jobs/apply with a job_id. You get back a session_id and a live_view_url (optional live cloud browser). 2. Poll. GET /jobs/apply/:id (MCP get_apply_status) until a terminal status. The response carries status, form_progress (required_filled / required_total / updated_at), field_fills, final_fields, and proxy_contact_reasons. Treat status as the source of truth — only completed means the application was submitted. Other common values: queued, running, awaiting_input, paused, failed, cancelled, stopped. 3. Stop. POST /jobs/apply/:id/stop (MCP stop_apply_for_job) cancels a running session.

curl -s -X POST "https://api.worklittle.com/jobs/apply" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "job_id": "JOB_ID" }'

curl -s "https://api.worklittle.com/jobs/apply/SESSION_ID" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY"

Idempotency, webhooks, and Recents

Pass Idempotency-Key (8–200 chars, A–Z a–z 0–9 . _ : -) on POST /jobs/apply. The same key returns the same session for 24 hours (idempotent_replay: true).

Optional webhook_url (HTTPS) on start receives POST JSON when status becomes awaiting_input, paused, completed, failed, stopped, or cancelled. Header X-Worklittle-Apply-Event is apply.session.<status>. Delivery retries up to 3 times. You can still poll. Browser Runs stay queued on Cloudflare, so you do not hold an HTTP stream.

A personal API key also writes the run to the key owner's worklittle.com Recents. That chat is watch-only. Start returns chat_id, chat_url, and user_id (chat_url is null for company-org keys). Company keys do not create a consumer chat.

Verification codes and proxy contact

Employer forms sometimes require an email or SMS verification code before they accept a submission. A session may use a temporary email alias or SMS number so the code can be read and entered automatically. Your candidate's real contact details still go on the application wherever the form allows it.

The session response explains itself: proxy_contact_reasons tells you exactly why a proxy was used for a given field. Surface that in your UI rather than hiding it, because candidates reasonably want to know which address an employer will reply to.

Tracking what you applied to

Applies made with your API key are attributed to the key owner's Worklittle account automatically, both for hosted apply and Apply with AI. For off-platform flows your agent drives by hand, record them yourself so the user's pipeline stays complete:

| Route | MCP tool | Purpose |
| --- | --- | --- |
| `GET /jobs/applied` | `list_applied_jobs` | Read the pipeline |
| `GET /jobs/saved` | - | Board total + per-stage counts |
| `POST /jobs/applied` | `track_applied_job` | Record an off-platform apply |
| `PATCH /jobs/applied/:job_id` | `update_applied_job_status` | Move to interview, offer, rejected, withdrawn |

Tracking calls are free. Stages are saved, in_progress, applied, interview, offer, rejected, withdrawn, and skipped.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| Starting a session without checking the eligibility flag | Read `can_apply` on the job first |
| Treating a start response as a completed application | Poll `get_apply_status` / `GET /jobs/apply/:id` until `status` is `completed` (or another terminal like `failed` / `paused`) |
| Retrying a failed start in a tight loop | Concurrent starts burn capacity. Back off and check the failure reason |
| Calling `POST /jobs/:id/apply` on an index-only listing | That returns 404. Use the employer `apply_url` or Apply with AI |
| Skipping `application_fields` on hosted apply | Read the job detail first so required custom questions are answered |

Related docs

Start here: Apply for jobs. Eligibility and closures: Closed jobs and eligibility. Hosted board apply: Embedded job board. Document attachments: Resumes and cover letters. Prompting an apply agent: Prompting for applications.