> ## Documentation Index > Fetch the complete documentation index at: https://docs.ishlabs.io/llms.txt > Use this file to discover all available pages before exploring further. # Create Task > Register a task: a named intent a session can bind by id. Registering is optional. Do it when runs have to stay comparable across a boundary the session itself cannot draw, such as the same task across two environments or across a month of builds. A one-off task belongs inline on the session. Send an `Idempotency-Key` header to make retries safe: the same key with the same body replays the original task as a 200, and the same key with a different body is a 409. `get_or_create` is the older, coarser flag and still works. Note what it does NOT do: on a name match it returns the existing task untouched and ignores every other field you sent, so a request whose instructions have drifted succeeds while changing nothing. Prefer `Idempotency-Key` for retries and PATCH to reconcile content. ## OpenAPI ````yaml /api/openapi.public.json post /api/v1/workspaces/{workspace_id}/tasks openapi: 3.1.0 info: contact: name: ish developer platform url: https://docs.ishlabs.io/ description: > The ish Developer API: the entry point for getting human feedback on whatever you're building, in whichever format you need. Its first surface is **sessions**: you open a session for one of your people inside *your own* environment, submit what that person perceives (human-sensory observations: a rendered screen, an error message) along with the set of actions your environment currently offers, and they decide one action per turn and tell you how it felt. Your code executes the chosen action and loops. **The loop is decide-only: ish never locates, drives, or executes anything inside your environment.** You stay in control of what runs; we tell you what a person would do next and why. ## Vocabulary The public vocabulary is **workspace**, **person**, **environment**, and **session**, and the wire uses these names directly: - `workspace_id`: the workspace that owns the person and is billed for the session (the create path is `/workspaces/{workspace_id}/sessions`). - `person_id`: the person the session drives. Two kinds are available to you: the ones your workspace owns, and the ones published in the shared ish library. Both are listed and searchable under `/v1/workspaces/{workspace_id}/people`, and each carries an `owner` saying which it is. - `environment_id`: a registered environment in that workspace: a named target with its own operating notes and default action vocabulary. Register one and reference it, or describe an ad-hoc one inline on the session; supply exactly one of the two. **"Session" here means one API session: a single person working toward one task in your environment, turn by turn.** It is not the ish product's notion of a study session (someone sitting down with a study), and it is unrelated to a browser session. Sessions live under `/v1/sessions`. ## Authentication All requests use a bearer token: `Authorization: Bearer `. The token is a **workspace API key** (prefix `ish_sk_live_`), a workspace-scoped machine principal minted in Settings > Developers and shown exactly once at mint. Scopes: `sessions:run` (create, submit turns, close), `sessions:read` (read the session and trace), `environments:read` / `environments:write` for the environment registry, `tasks:read` / `tasks:write` for the task registry, `people:read` / `people:write` for the people you can run a session for, and `usage:read` for this workspace's consumption, limits and rate-limit budgets. Keys are minted with `sessions:run`, `sessions:read`, and `tasks:read`; ask for any `:write` scope, and for `people:read` and `usage:read`, explicitly. `usage:read` is never implied by another scope: it covers the shape of the whole workspace's operation, not just the lane a key was minted for. An ish user access token (JWT) also works on the same header for personal scripts; server integrations should use keys. ## Versioning & forward-compatibility The API is versioned in the URL path (`/api/v1`). Several enum-typed and block-typed fields are **open unions**: new values may be added over time, and clients MUST tolerate values they do not recognize rather than failing on them. The field descriptions call these out. ## Correlation & errors Every response carries an **`X-Request-Id`** header; quote it in support requests. Error responses additionally echo it in the body as `request_id`. Two error-body shapes exist; parse defensively, they differ: - **`ValidationError`**: the request-validation layer (HTTP 422): a malformed body (wrong types, missing fields, an invalid observation `type`, a bad enum value, `parameters` that don't fit the model). A field-level envelope (`error_code`, `errors[]`, `suggestions[]`; `suggestions` is CLI-oriented boilerplate; ignore it for API use). - **`Error`**: everything else, a `{ detail, request_id }` envelope. This covers the handler layer's business-rule 422s (e.g. `exactly one image observation block is required`; `person has no renderable background`) as well as 401 / 402 / 403 / 404 / 409 / 429 / 502. That is why 422 is documented on the responses below as either shape (`oneOf`). **Branch on `detail.error_kind`, not on the status code.** On every refusal this API classifies, `detail` is an object rather than a string: ```json { "detail": { "error_kind": "turn_index_mismatch", "message": "expected turn_index 4, got 3", "expected_turn_index": 4 }, "request_id": "9f2c...", "docs_url": "https://docs.ishlabs.io/api/errors#turn_index_mismatch" } ``` `error_kind` is the stable, machine-readable classification; `message` is for humans and may be reworded; any further keys carry the specifics you would act on. One status often covers several kinds with different remedies. A 402 is either "top up" or "raise your cap"; a 429 is either "slow down" or "you are out of sessions for today". The status alone is not enough to decide what to do. `docs_url` links to that kind's entry in the error catalog. The set of kinds is an **open union**: new ones are added as new refusals are classified, so treat an unfamiliar `error_kind` as "an error of this status class" rather than failing on it. `message` is always present. ## Rate limits API keys carry a per-key request budget and, on session creates, a per-key daily session quota. Exceeding either is a `429` with a `Retry-After` header (also echoed as `detail.retry_after_seconds`) and a distinct `error_kind`: `rate_limited` resets within the minute, `session_quota_exceeded` on a day boundary. Both are transient and neither affects sessions that are already open. You do not have to wait for the `429` to find out. Every key-authed response, including the `429` itself, carries the budget it just spent: - **`x-ratelimit-limit`**: the ceiling for that window. - **`x-ratelimit-remaining`**: what is left in it after this request. - **`x-ratelimit-reset`**: **seconds from now** until the window resets. A delta, not a Unix timestamp. When a request charges more than one budget (a session create spends both), the headers describe the one closest to refusing you, so pacing off `remaining` is always pacing off the binding constraint. Treat all three as optional: they are absent when nothing was charged, and `reset` alone can be omitted if the limit backend cannot be read at that moment. User access tokens are deliberately not rate limited, so their responses carry no `x-ratelimit-*` headers. The per-key budgets exist because a key is a machine principal that can loop unattended; an interactive session is bounded by the person driving it. license: identifier: LicenseRef-Proprietary name: Proprietary title: ish Developer API version: 1.6.1 servers: - description: Production url: https://api.ishlabs.io security: - bearerAuth: [] tags: - description: >- Open a session for one of your people inside your own environment, submit what they perceive turn by turn, and read back the decision they made and how it felt. name: sessions - description: >- Register the targets your sessions run against, and the declared versions of each one. A registered environment carries its own operating notes and default action vocabulary, so a session only has to name it. name: environments - description: >- Register the intent a session works toward, so runs stay comparable across environments and over time. A session can also describe its instructions inline and skip the registry entirely. name: tasks - description: >- Find the person a session should run as. Read and search the pool you can draw on: the people your workspace owns, plus the ones published in the shared ish library. Read-only at this version. name: people - description: >- What this workspace has consumed, and what bounds it: the session usage series over time, the spend cap and the credits drawn against it, and the live rate-limit budgets this credential is spending. Read-only. name: usage paths: /api/v1/workspaces/{workspace_id}/tasks: post: tags: - tasks summary: Create Task description: >- Register a task: a named intent a session can bind by id. Registering is optional. Do it when runs have to stay comparable across a boundary the session itself cannot draw, such as the same task across two environments or across a month of builds. A one-off task belongs inline on the session. Send an `Idempotency-Key` header to make retries safe: the same key with the same body replays the original task as a 200, and the same key with a different body is a 409. `get_or_create` is the older, coarser flag and still works. Note what it does NOT do: on a name match it returns the existing task untouched and ignores every other field you sent, so a request whose instructions have drifted succeeds while changing nothing. Prefer `Idempotency-Key` for retries and PATCH to reconcile content. operationId: createTask parameters: - in: path name: workspace_id required: true schema: format: uuid title: Workspace Id type: string - in: header name: Idempotency-Key required: false schema: anyOf: - type: string - type: 'null' title: Idempotency-Key requestBody: content: application/json: examples: default: summary: Register a task with verification steps value: background: >- You ordered a jacket last week. It arrived in the wrong size. instructions: Find the refund policy and start a return. name: Return a delivered order steps: - name: Open order history - name: Start a return on the jacket schema: $ref: '#/components/schemas/CreateTaskRequest' required: true responses: '200': content: application/json: schema: $ref: '#/components/schemas/TaskResponse' description: >- The existing task, RETURNED AS IS: nothing on this request was applied to it. Two paths reach here: an `Idempotency-Key` replay (same key, same body), or `get_or_create` with a live task already holding this name. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '201': content: application/json: schema: $ref: '#/components/schemas/TaskResponse' description: Successful Response headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '401': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- The bearer token is missing, malformed, unknown, or revoked (`detail.error_kind = 'invalid_api_key'`). One kind covers all four deliberately: distinguishing them would confirm which guesses are real keys. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '403': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- The API key lacks the `tasks:write` scope (`detail.error_kind = 'insufficient_scope'`, with `detail.required_scope = 'tasks:write'`). Mint a key that includes it; an ish user access token is unconstrained by scopes. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '404': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- The workspace (`workspace_id`) was not found, or is not reachable with this credential. `detail.error_kind` is `workspace_not_found`. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '409': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- `detail.error_kind` is `task_name_taken` (a task with this name already exists in the workspace; names are unique per workspace, case-insensitive) or `idempotency_conflict` (the `Idempotency-Key` was reused with a different request body). headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '422': content: application/json: schema: oneOf: - $ref: '#/components/schemas/ValidationError' - $ref: '#/components/schemas/Error' description: >- Validation error. A request-shape failure uses the `ValidationError` envelope; a handler-raised domain-validation refusal uses the `Error` envelope. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' '429': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- The API key's request rate limit is exceeded (`detail.error_kind = 'rate_limited'`). Transient: retry after the `Retry-After` interval, also echoed as `detail.retry_after_seconds`. Not applied to user access tokens. headers: X-Request-Id: $ref: '#/components/headers/XRequestId' x-ratelimit-limit: $ref: '#/components/headers/XRateLimitLimit' x-ratelimit-remaining: $ref: '#/components/headers/XRateLimitRemaining' x-ratelimit-reset: $ref: '#/components/headers/XRateLimitReset' security: - bearerAuth: [] components: schemas: CreateTaskRequest: additionalProperties: false properties: background: anyOf: - maxLength: 8000 type: string - type: 'null' description: >- Background the person is treated as already knowing. Accepted and stored; not yet consumed by API sessions, which currently render the instructions only. title: Background get_or_create: default: false description: >- Idempotent register for CI: when a live task with this name (case-insensitive, per workspace) already exists, return it with 200 instead of 409. The existing task is returned as is: nothing on this request is applied to it. title: Get Or Create type: boolean instructions: description: >- What the person is trying to do, in their own terms. Rendered into their prompt as the situation paragraph, exactly as a session's inline instructions are. maxLength: 2000 minLength: 1 title: Instructions type: string name: maxLength: 120 minLength: 1 title: Name type: string steps: anyOf: - items: $ref: '#/components/schemas/TaskStep' maxItems: 50 type: array - type: 'null' description: >- The atomic actions a run should be checked against afterwards. Never shown to the person doing the run. Step ids are permanent identity: an id you supply is kept verbatim, a missing one is minted server-side. Accepted and stored; not yet consumed by API sessions. title: Steps required: - name - instructions title: CreateTaskRequest type: object TaskResponse: description: A registered task as the caller sees it. properties: archived_at: anyOf: - format: date-time type: string - type: 'null' description: >- Set when the task is archived (DELETE). An archived task stays readable by id so existing sessions keep resolving, is hidden from the default list, refuses new sessions (409), and frees its name for reuse. title: Archived At background: anyOf: - type: string - type: 'null' description: >- Background the person is treated as already knowing, or null. Accepted and stored; not yet consumed by API sessions, which currently render the instructions only. title: Background created_at: format: date-time title: Created At type: string id: format: uuid title: Id type: string instructions: title: Instructions type: string name: title: Name type: string revision: description: >- Increments on every write to this task. Sessions freeze the revision they bound, so runs are comparable within a revision of the content. title: Revision type: integer steps: anyOf: - items: $ref: '#/components/schemas/TaskStepView' type: array - type: 'null' description: >- The actions a run is checked against afterwards, or null when the task has none. Steps are never shown to the person doing the run. Accepted and stored; not yet consumed by API sessions. title: Steps updated_at: format: date-time title: Updated At type: string workspace_id: format: uuid title: Workspace Id type: string required: - id - workspace_id - name - instructions - background - steps - revision - archived_at - created_at - updated_at title: TaskResponse type: object Error: description: >- Generic error envelope for 4xx/5xx responses other than request-shape validation. properties: detail: anyOf: - type: string - additionalProperties: true type: object description: >- A human-readable message, OR a structured object carrying a machine-readable `error_kind` (e.g. `idempotency_conflict`, `turn_index_mismatch`, `decision_invalid`). title: Detail docs_url: description: >- Link to this error's entry in the error catalog. Present whenever `detail` carries a registered `error_kind`; absent on unclassified errors. title: Docs Url type: string request_id: description: >- Correlation id; identical to the `X-Request-Id` response header. Quote it in support requests. title: Request Id type: string required: - detail - request_id title: Error type: object ValidationError: description: >- Request body / parameter validation failure (HTTP 422). A field-level envelope so callers can pinpoint the offending field, value, and allowed values without parsing prose. properties: detail: title: Detail type: string error: title: Error type: string error_code: description: Stable machine code, e.g. `validation_error`. title: Error Code type: string errors: items: $ref: '#/components/schemas/FieldError' title: Errors type: array retryable: title: Retryable type: boolean status: title: Status type: integer suggestions: items: type: string title: Suggestions type: array required: - error - error_code - status - retryable - detail - errors title: ValidationError type: object TaskStep: description: >- One atomic action, for verifying after the session what the person actually accomplished. `name` is required (a short verb phrase); `description` is optional nuance. `id` is the step's permanent identity: send back an id you already hold and it is kept verbatim, or omit it and one is derived from the name. Responses always carry it. properties: description: anyOf: - maxLength: 500 type: string - type: 'null' title: Description id: anyOf: - maxLength: 64 type: string - type: 'null' title: Id name: maxLength: 80 minLength: 1 title: Name type: string required: - name title: TaskStep type: object TaskStepView: description: A stored step as the caller sees it (id always present). properties: description: anyOf: - type: string - type: 'null' title: Description id: title: Id type: string name: title: Name type: string required: - id - name title: TaskStepView type: object FieldError: description: One field-level entry in a ValidationError envelope. properties: allowed_values: description: For enum/literal failures, the accepted values. items: {} title: Allowed Values type: array input: anyOf: - type: string - type: number - type: boolean - type: 'null' description: Offending value (truncated); omitted for containers. title: Input loc: description: Path to the offending field. items: anyOf: - type: string - type: integer title: Location type: array msg: title: Message type: string type: title: Error Type type: string required: - loc - msg - type title: FieldError type: object headers: XRequestId: description: >- Per-response correlation id, present on EVERY response (success and error). Error bodies echo it as `request_id`. schema: type: string XRateLimitLimit: description: >- Ceiling for the rate-limit window this request charged. Present on responses made with an API key against a rate-limited operation, including the `429` itself; absent for user access tokens (which carry no per-key budget) and when the rate-limit backend could not be read. schema: type: integer XRateLimitRemaining: description: >- Requests left in that window AFTER this one was counted. Pace off this rather than waiting for a `429`. schema: type: integer XRateLimitReset: description: >- **Seconds from now** until that window resets (a delta, NOT a Unix timestamp). Measured when the response is written. Omitted on the rare occasion the reset instant could not be read, while `limit` and `remaining` are still published. schema: type: integer securitySchemes: bearerAuth: description: >- Workspace API key as a bearer token: `Authorization: Bearer ish_sk_live_...`. Keys are workspace-scoped machine principals minted in Settings > Developers (shown once at mint). Scopes: `sessions:run` (create a session, submit turns, close), `sessions:read` (read the session and its decision trace), `environments:read` and `environments:write` (manage the workspace's registered environments), `tasks:read` and `tasks:write` (manage the workspace's registered tasks), `people:read` and `people:write` (the people the workspace can run a session for), and `usage:read` (the workspace's own consumption, spend limits and rate-limit budgets). A key is minted with `sessions:run`, `sessions:read`, and `tasks:read` by default; every other scope must be requested, `people:read` and `usage:read` included. An ish user access token also works on the same header for personal scripts. scheme: bearer type: http ````