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.

Embedded job board

Ship a careers site on your own domain with the public job-board endpoints. No API key, CORS open, ETag caching, resume autofill, and JSON-LD for search engines.

A company board lists only what that employer published on Worklittle. It is not a filtered view of the global index for that company slug.

Board endpoints versus the global index

These are two different datasets and mixing them up is the number one source of confusion.

| | `GET /jobs` | `GET /business/jobs/company/:company/...` |
| --- | --- | --- |
| Scope | Market-wide index of millions of roles | Only roles that employer published on Worklittle |
| Auth | Bearer API key with `jobs:read` | None required |
| Billing | Per job returned | Free, IP rate limited |
| Apply | Often an off-platform `apply_url` | Hosted apply on the board |
| Best for | Discovery, matching, research | A branded careers page |

If your careers page shows roles for one employer, you want the board endpoints and you do not need a key at all. If you are aggregating across employers, you want the index. Applying for jobs: Apply for jobs.

Architecture

A complete careers site is four calls plus a webhook.

1. List with branding and facets.

curl -s "https://api.worklittle.com/business/jobs/company/acme/board?limit=25&include=facets&department=Engineering&workplace_type=remote"

Each job carries slug and url_path, so you can map straight onto your own /careers/{slug} routes instead of exposing opaque ids. Filters available: q, department, workplace_type, employment_type, location.

2. Load one job for the apply page.

curl -s "https://api.worklittle.com/business/jobs/company/acme/jobs/growth-engineer"

The :id segment accepts a public_job_id, a posted job id, or a slug. Detail includes application_fields, description_sections, and features.

3. Optionally autofill from a resume with POST .../parse-resume, but only when features.resume_autofill is true.

4. Submit with POST /business/jobs/company/:company/jobs/:id/apply or, with an API key, POST /jobs/:id/apply / MCP submit_job_application.

Apply payload

Load application_fields from job detail first. Built-in ids include name, email, phone, resume_file, cover_letter, linkedin_url, github_url, and website_url. Custom fields use kind: "custom" (short_text, long_text, dropdown, file_upload, yes_no). Put custom answers under answers.

| Field | Notes |
| --- | --- |
| `name` or `full_name` | Required when the job's `name` builtin is required |
| `email`, `phone` | Required when those builtins are required |
| `resume_file` / `cover_letter_file` | `{ "filename", "content_base64", "mime?" }`, max 10 MB. PDF, DOC/DOCX, RTF, TXT/MD, images |
| `resume_text`, `cover_letter` | Plain text |
| `answers` | Custom field ids from `application_fields` |
| `similar_job_alerts` | Public board: required `true` or `false` when the feature is on. API apply: optional opt-in |
| `metadata` | API apply only, 4k JSON cap |

API key apply:

curl -s -X POST "https://api.worklittle.com/jobs/JOB_ID/apply" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Alex Rivera","email":"alex@example.com","phone":"+14155550100"}'

Public board apply (no key):

curl -s -X POST "https://api.worklittle.com/business/jobs/company/acme/jobs/JOB_ID/apply" \
  -H "Content-Type: application/json" \
  -d '{"name":"Alex Rivera","email":"alex@example.com","phone":"+14155550100","similar_job_alerts":true}'

Success is 201 with application.id. API apply also returns people_search_profile, ats (queued or skipped_no_organization), and billing ($0.01 per successful submit).

Parse resume

When the job has resume_file and features.resume_autofill is true:

curl -s -X POST "https://api.worklittle.com/business/jobs/company/acme/jobs/JOB_ID/parse-resume" \
  -H "Content-Type: application/json" \
  -d '{"resume_file":{"filename":"resume.pdf","content_base64":"JVBERi0xLjQK..."}}'

Returns { "autofill": { … }, "status": "ok" }. Cached about 2 hours per resume hash + job. No resume field → 400. Autofill off → 400 resume_autofill_disabled (upload on apply still works).

Read features before you build UI

Board capabilities are org toggles that appear as a features object on the board profile, list, and detail responses. Read them instead of hardcoding.

| Feature | Default | When `false` |
| --- | --- | --- |
| `resume_autofill` | `true` | `parse-resume` returns **400** `resume_autofill_disabled`. Resume upload on apply still works |
| `similar_job_alerts` | `true` | The board apply payload no longer requires the field |

One quirk worth internalizing: when similar_job_alerts is on, public board apply requires the field to be an explicit true or false. Omitting it is a validation error, because the hosted form asks the candidate a real Yes or No question. The API apply route treats the same field as an optional opt-in.

Set toggles with PUT /v1/employer/organization:

{ "board_features": { "resume_autofill": true, "similar_job_alerts": false } }

Caching, SEO, and freshness

Board GETs send weak ETag headers. Send If-None-Match and handle 304 so your edge cache stays cheap. Adding an optional Bearer key raises the GET rate limit substantially, typically to around 600 per minute versus 120 per minute per IP. Fetch GET /business/jobs/company/:company/jobs/:idOrSlug/json-ld?canonical_url=https://example.com/careers/slug for Google JobPosting structured data, and set the canonical to your own URL. Prefer webhook-driven revalidation over polling. Subscribe to job.published, job.updated, and job.closed, each of which carries public_job_id, slug, organization.slug, public_visible, and accepting_applicants so you know exactly which page to invalidate. See Webhooks. * Keep sitemap URLs aligned to public slugs, not internal ids.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| Expecting every company's index jobs on their board | Boards only show roles published through Worklittle |
| Building the apply form from list rows | `application_fields` only comes from the detail endpoint |
| Hardcoding a resume upload widget | Check `features.resume_autofill` first |
| Omitting `similar_job_alerts` on board apply | Send an explicit boolean unless the feature is off |
| Polling the board every minute for changes | Use ETags plus `job.*` webhooks |
| Routing users by opaque id | Use `slug` and `url_path` |

Stable error codes you should handle by name: role_closed, duplicate_application, validation_error, resume_autofill_disabled, and RATE_LIMITED.

Related docs

Publishing side: Post a job. Applying for jobs: Apply for jobs. Event-driven revalidation: Webhooks reliability. Clients: SDK, OpenAPI.