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 submit by default; pass auto_submit: false to review first. Hosted apply is a different path: it posts JSON to a Worklittle-published job.

Two apply paths, one decision

| Path | Use when | Endpoint | Cost |
| --- | --- | --- | --- |
| **Apply with AI** | The role is on the employer's own site and `can_apply` is `true` | `POST /jobs/apply`, MCP `apply_for_job` | AI tokens at published rates, about $0.01–$0.03 per successful session |
| **Hosted apply** | The employer published the role on Worklittle | `POST /jobs/:id/apply`, MCP `submit_job_application` | Free |
| **Public board apply** | Careers site on the employer's board, no API key | `POST /business/jobs/company/:company/:idOrSlug/submit-application` | Free, IP rate limited |

Hosted apply returns 404 for index-only listings. Scope: jobs:apply.

POST /jobs/apply also accepts hosted jobs. When job_id is a Worklittle-hosted job and the body carries name, email, resume_text, resume_file, or answers, it submits through hosted apply and returns "kind": "submitted". Otherwise it starts a session and returns "kind": "session".

can_apply is the only check

GET /jobs and GET /jobs/:id return a boolean can_apply. It is the only supported way to know whether a session can run. Over 4 million open listings currently return true. It already accounts for supported forms, the per-job bot denylist, and board cooldowns. Do not infer eligibility from source_name, apply_url, or the careers host.

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}'

can_apply is independent of closed_at. Re-read the job right before starting. See Closed jobs and eligibility.

Run a session

Apply with AI is full automation for eligible employer forms: start a session, it fills the form from the candidate's resume, and it submits. On worklittle.com the same run shows a cloud browser in chat so the person can watch.

1. Start. POST /jobs/apply with job_id. The response has kind: "session" and a session object with id (the session id), status, and live_view_url, plus queued, chat_id, chat_url, and user_id. 2. Poll. GET /jobs/apply/:id (MCP check_application_status) returns { session, field_fills, final_fields }. Poll session.status until it is terminal. Only completed means the application was submitted. 3. Stop a running session with POST /jobs/apply/:id/stop (MCP stop_application). MCP list_active_applications (GET /v1/apply-with-ai/active) returns sessions, each with id, job_id, and status.

curl -s -X POST "https://api.worklittle.com/jobs/apply" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY" \
  -H "Idempotency-Key: apply-JOB_ID-user-123" \
  -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"

API keys submit by default. Pass auto_submit: false to stop at review: the session waits as awaiting_submit, you read the answers from GET /v1/apply-with-ai/:id (final_fields), then send it with POST /v1/apply-with-ai/:id/approve-submit. Worklittle holds up to 200 global Browser Run slots at once. When they are full, the session starts queued (Waiting) until a slot frees. There is no per-user concurrency cap. Credit and Instant gate spend.

| `status` | Meaning |
| --- | --- |
| `queued`, `running` | In progress |
| `awaiting_submit`, `awaiting_input`, `paused` | Waiting on the applicant. Not final, can be resumed |
| `completed` | Submitted |
| `failed`, `cancelled`, `stopped` | Ended without a submission |

Session fields (inside session):

| Field | Notes |
| --- | --- |
| `form_progress` | `required_filled`, `required_total`, `updated_at`. `null` until the form is read |
| `field_fills`, `final_fields` | Top-level next to `session`. What was entered |
| `stop_message` | One to three plain sentences you can show the person as-is. Present on every stop without a submission |
| `stop_category` | `job_closed`, `already_applied`, `captcha`, `assessment`, `video_interview`, `documents`, `sign_in`, `email_verification`, `missing_answer`, `form_error`, `site_error`, `provider_capacity`, `timeout`, `other` |
| `stop_reason` | Finer code, for example `validation_unresolved`, `futile_stall`, `site_error`, `documents_required` |
| `required_documents` | String array. Set with `stop_reason: "documents_required"` when the employer wants transcripts, references, writing samples, and similar. Worklittle never invents them. Send the person to the employer site. `null` otherwise |
| `proxy_contact_reasons` | Why a temporary email or SMS number was used for a verification code |
| `submit_blocked_reason`, `error_message` | Why a run is held or failed, when known |

When a run signs in to or creates an employer portal account (Workday), the saved login is reused by later applications to the same employer.

Idempotency, webhooks, and Recents

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 with session.idempotent_replay: true. Use it on timeouts instead of retrying blindly. webhook_url (HTTPS) on start receives a POST when status becomes awaiting_submit, awaiting_input, paused, completed, failed, stopped, or cancelled. Header X-Worklittle-Apply-Event is apply.session.<status>. The JSON body is { event, session_id, status, session, delivered_at }. Up to 3 delivery attempts, each with a 10 second timeout. Polling still works. * A personal key also writes the run to the owner's worklittle.com Recents (watch-only). Start returns chat_id, chat_url, user_id. chat_url is null for company-org keys.

Cost model

Apply with AI bills AI tokens at published rates (Jobs pricing). Spend debits the key owner's Personal organization and appears as AI job apply on Usage. Failed starts still bill tokens already used, so do not retry a rejected start in a loop.

If the Personal organization has Worklittle Instant ($9.99/month, $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 pay as you go, assuming most of the credit goes to applies.

Tracking what you applied to

Applies made with your key are attributed to the owner's account. Record off-platform applies yourself. Tracking calls are free.

| Route | MCP tool | Purpose |
| --- | --- | --- |
| `GET /jobs/applied` | `list_applied_jobs` | Jobs in the `applied` stage (limit defaults to 50) |
| `GET /jobs/saved` | - | Board total and per-stage counts. Add `?status=<stage>` to list one stage |
| `POST /jobs/applied` | `track_applied_job` | Record an off-platform apply |
| `PATCH /jobs/applied/:job_id` | `update_applied_job_status` | Change stage |

Stages: saved, in_progress, applied, interview, offer, rejected, withdrawn, viewed, skipped. Scope: jobs:read or jobs:apply.