Skip to main content

API: status and bulk actions

Change the workflow status of a single issue, or apply status and tag changes to many issues at once. Both operate on issues (error groups) in the current application. See API conventions for base URL, auth, and headers.

Issue status​

Move one issue to a new status and record the change in its history. Requires the issue id, a target status, and an optional note.

FieldTypeNotes
idintThe issue (error group) id.
statusstringOne of the statuses below.
notestringOptional; trimmed. Stored on the history entry.

Valid statuses:

open  in_progress  fixed  wont_fix  reoccurred

Any other value is rejected. An unknown id returns an "Issue not found" error. On success the issue's status_updated_at is set to the current time, a history row is written (recording the previous and new status), and the response echoes the transition:

{ "id": 42, "from_status": "open", "status": "fixed", "note": "Patched in 3.2.1" }

See Workflow status and history for how transitions are tracked.

Bulk issues​

Apply one action to a set of issue ids in a single transaction. If any id fails validation, the whole batch is rolled back.

FieldTypeNotes
idsint[]1-200 ids. Duplicates and non-positive values are dropped.
actionstringstatus, add_tag, or remove_tag.
statusstringRequired for status; same values as above.
notestringOptional for status; max 10,000 characters.
tag_idintRequired for add_tag / remove_tag; must exist.

The status action updates every listed issue and writes a history row for each. add_tag attaches an existing tag (as a manual tag, re-marking an existing link as manual); remove_tag detaches it. Every id must belong to the current application, or the batch fails.

Responses report the action, target, and affected ids:

{ "action": "status", "status": "fixed", "note": "", "updated": 3, "ids": [7, 8, 9] }
{ "action": "add_tag", "tag_id": 5, "updated": 3, "ids": [7, 8, 9] }

Assignment (Laravel-hosted only)​

POST /?api=assign-issue and GET /?api=assignable-users let you assign an issue to a person — but only when Log Lens is mounted inside a Laravel host app that supplies an assignable-users callable (see Roles & assignment). Standalone has no user table of its own to assign from, so assignable-users always returns an empty list there and assignment is a no-op — this is a deliberate scope decision, not a bug.

FieldTypeNotes
idintThe issue to (un)assign.
assigned_to_idstring, nullableAn opaque id from the host's assignable-users list. Omit or send empty to unassign.
assigned_to_labelstringRequired when assigning; the display name shown in the dashboard.
POST /?api=assign-issue
{"id":42,"assigned_to_id":"usr_9f2","assigned_to_label":"Priya N."}

assigned_to_id/assigned_to_label are stored as an opaque pair, not a foreign key — Log Lens has no users table to reference. GET /?api=assignable-users returns {data:[{id, label}]}, sourced from the host app and scoped to the current application (a host can return different people per application).