Jobs API

Work with SeeLLM jobs, actions, and implementation references.

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

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

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

Get a Job

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

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

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.