Skip to main content
PATCH
/
api
/
incidents
/
v1
/
{incident_id}
/
assign-owner
AssignIncidentOwner
curl --request PATCH \
  --url https://developer.synq.io/api/incidents/v1/{incident_id}/assign-owner \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "actor": {
    "name": "<string>",
    "email": {
      "userEmail": "jsmith@example.com"
    },
    "via": "VIA_UNSPECIFIED"
  },
  "ownerEmail": "<string>"
}
'
{}

Documentation Index

Fetch the complete documentation index at: https://docs.synq.io/llms.txt

Use this file to discover all available pages before exploring further.

Authorizations

​
Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

​
incident_id
string<uuid>
required

ID of the incident to assign the owner to

Body

application/json
​
actor
Actor · object
required

Actor identifies who performed a write — set by the calling client and carried end-to-end through the public API into stored audit trails (issue status changes, comments, incident assignments) and rendered downstream (e.g. Slack/MSTeams/email alerts).

Producers should populate:

  1. name — human-readable display label, derived from synq.auth.iam.v1.IamResponse.user_name when available, falling back to user_email. Avoid generic placeholders ("MCP", "API"); readers treat those as "no identity resolved" and fall back to impersonal copy.
  2. user — the strongest identifier the caller can prove. For human callers, set email from IamResponse.user_email so the server can resolve the caller back to a workspace user.
  3. via — entry-point label for the channel through which the request arrived (e.g. VIA_MCP for the MCP server), regardless of who the caller is.
​
ownerEmail
string

Response

200 - application/json

Success

The response is of type AssignIncidentOwnerResponse · object.