---
title: Jobs API
description: Work with SeeLLM jobs, actions, and implementation references.
audience: [human, agent]
type: reference
version: v1
stability: stable
lastVerified: "2026-08-01"
prerequisites: [/docs/api/authentication/]
related: [/docs/api/agent-hooks/, /docs/api/, /docs/evidence-model/]
artifacts: [{ label: OpenAPI contract, url: /docs/api/openapi.json }]
---

Jobs are the workflow layer in SeeLLM. A job describes the important work your team should decide on. Patches, edge pages, manual tasks, and agent deliveries are implementation details attached to a job action.

Use the generated [OpenAPI contract](/docs/api/openapi.json) for request and response schemas. All endpoints require bearer authentication. `GET /jobs` returns every job in the authenticated organization, newest first; it has no pagination or filter parameters.

## Object Model

```text
Job
  Action
    Implementation: patch | edge_page | manual | agent_hook
```

Use Jobs when your system needs to answer: “What important thing does SeeLLM want us to do?”

Use Patches or Edge Pages when your system needs to answer: “How will this approved job be executed?”

## List Jobs

```bash
curl https://api.seellm.link/api/jobs \
  -H "Authorization: Bearer sk_live_your_api_key_here"
```

## Get a Job

```bash
curl https://api.seellm.link/api/jobs/job_your_job_id \
  -H "Authorization: Bearer sk_live_your_api_key_here"
```

## Create a Job from an Autopilot Task

```bash
curl -X POST https://api.seellm.link/api/jobs/from-autopilot-task \
  -H "Authorization: Bearer sk_live_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{"task_id":"task_your_task_id"}'
```

When the job is created, SeeLLM sends `job.created` to active Agent Hooks subscribed to that event.

## Approve a Job Action

```bash
curl -X POST https://api.seellm.link/api/jobs/job_your_job_id/actions \
  -H "Authorization: Bearer sk_live_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "action_id": "approve_fix",
    "implementation_type": "patch",
    "implementation_id": "patch_123",
    "note": "Ship the answer-first patch."
  }'
```

`implementation_type` can be:

- `patch`
- `edge_page`
- `manual`
- `agent_hook`

If you do not have a concrete implementation ID yet, use `manual` or create the execution artifact first and attach its ID later.

`implementation_id` is optional. The API does not accept an idempotency key for job creation or action submission, so do not automatically repeat a timed-out `POST` without reconciling the job first.

## Errors and Retries

Malformed bodies return HTTP `400` with `{ "error": "..." }`. Reads can return `401`, `403`, or `404`; an action can also return `409` when its requested implementation type is unavailable. Current write-role checks throw and surface HTTP `500` rather than an advertised `403`, so mutation clients should handle `500` and must not treat `403` as the role-denial contract. Observe the global rate-limit headers and retry HTTP `429` only after `Retry-After`; SeeLLM does not publish a job-specific timeout or retry policy.

## Statuses

Jobs can move through:

- `new`
- `reviewed`
- `approved`
- `sent`
- `dismissed`
- `resolved`

The job status is the user-facing workflow state. Implementation status tracks whether a patch, edge page, or external workflow has actually shipped.