404 exactly like one that never existed. Reads need evals:read. Writes need evals:write and the operator or owner role; marking an issue viewed needs evals:write only.
These routes answer in the compatibility envelope: {"data": ..., "errors": null} on success and {"data": null, "errors": [{"error", "message"}]} on a refusal the route itself makes (bad_request 400, not_found 404, conflict 409). A missing credential, scope or role, a body that cannot be read as a JSON object, and an agent_id the credential cannot read (on create, and as the issues list filter) are refused with the standard error envelope (Errors and limits). Lists page with limit and an opaque next_cursor; pass it back as cursor unchanged. The list routes refuse a query parameter they do not take; GET /v1/triage/categories, GET /v1/triage/issues/{id} and GET .../affected read none and ignore any you send. An issues list’s cursor belongs to the filters and sort it was made with: change one between pages and the cursor is refused as invalid.
Issues
An issue reads
id, triage_id (T-1001, numbered per workspace), number, org_id, the fields above except resource_links (which is never returned), author_id, created_at, updated_at, last_activity_at, resource_count, flag_count, relation_count and has_unread_activity (true until this credential marks the issue viewed, and again after any later activity). external_link and latest_agent_session are always null and is_processing is always false. Creating an issue is also the issue.created event your automation triggers can listen for (GET /v1/automation/events).
Evidence: calls
call_id names a conversation of an agent the credential can read; one it cannot read, or that does not exist, answers 404. A flag reads issue_id, call_id, agent_id, type, note, attached_by_id, org_id and created_at.
Files, comments, activity and links
File ids are the
id values GET /v1/files/list returns (knowledge:read), the knowledge documents of the agents the credential can read. Only files can be attached today.