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.

Overview

What to get right before you put a Worklittle integration in front of users: throttling and spend, stale jobs, webhook delivery, and a QA pass that catches the failures that do not raise errors.

The failures that hurt in production are the quiet ones. A 429 is obvious. An agent that confidently reports a salary nobody published is not.

The four failure classes

| Class | Looks like | Covered in |
| --- | --- | --- |
| **Throttling and budget** | 429s, 402s, a surprising invoice | [Retries and spend](/use-cases/retries-and-spend) |
| **Stale or ineligible data** | Apply fails, closed roles shown, sessions that never start | [Closed jobs and eligibility](/use-cases/closed-jobs-and-eligibility) |
| **Delivery gaps** | Your mirror drifts from Worklittle, duplicate records | [Webhooks reliability](/use-cases/webhooks-reliability) |
| **Silent correctness** | Invented facts, claimed writes, wrong candidate updated | [Eval checklist](/use-cases/eval-checklist) and [Grounding](/use-cases/grounding) |

The first three raise signals you can alert on. The fourth does not, which is why it needs a deliberate QA pass rather than monitoring alone.

Error shapes to handle by name

REST failures return a structured body:

{ "error": { "code": "RATE_LIMITED", "message": "…", "documentation_url": "https://docs.worklittle.com/help/api/rate-limits-and-429" } }

Auth, permission, billing, and throttle codes include documentation_url. Follow that Help page before retrying.

| HTTP | Code | Meaning | Response |
| --- | --- | --- | --- |
| 400 | `BAD_REQUEST` | Bad filter or payload | Fix the request, do not retry unchanged |
| 401 | `UNAUTHORIZED` | Missing or invalid key | Alert, do not retry |
| 402 | `PAYMENT_REQUIRED` | Payment failed or monthly limit hit | Stop metered work, fix card or limit at [**Billing**](https://worklittle.com/business/billing) - do not retry |
| 403 | `FORBIDDEN` | Missing scope or org role | Fix the key or the membership |
| 404 | `NOT_FOUND` | Unknown id, or no hosted apply | Re-resolve the id |
| 429 | `RATE_LIMITED` | Throttled | Back off, honor `Retry-After` |
| 500 | `INTERNAL_ERROR` | Upstream failure | Retry with backoff, cap attempts |

Over MCP the same conditions arrive as JSON-RPC errors. Upstream 429s and 5xx typically surface as -32603, so treat that code as retryable and -32602 as a request bug. Full tables: Errors.

Design for degradation

Decide in advance what your product does when Worklittle is slow, throttled, or out of balance, because the default of an error toast is rarely the right answer.

Cache the last good search and serve it with a staleness note rather than an empty state. Separate free from metered paths so a 402 does not take down tracking, board pages, or ATS reads that cost nothing. Queue writes. A failed stage update should retry from a queue with an idempotency key rather than being lost in a request handler. Make apply failures explicit. Never let a failed submit look like a success. Users will not check twice. * Keep board pages static-ish. ETags and webhook revalidation mean a careers site keeps serving even when your origin cannot reach the API.

Health is at GET https://api.worklittle.com/health, and the Status page covers incident visibility.

Pre-launch pass

Before shipping, confirm each of the following has a defined behavior rather than an accidental one.

1. A 429 during a user-visible search. 2. A 402 halfway through a multi-step agent turn. 3. A job that closes between search and apply. 4. An Apply with AI session that stalls on a question. 5. A webhook delivered twice. 6. A webhook never delivered. 7. A model asked about a salary the posting does not include. 8. A model asked to move a candidate whose name matches two people.

The concrete version of this list, with expected outcomes, is Eval checklist.