Skip to main content
POST
SetFoldEnabled

Authorizations

Authorization
string
header
required

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

Path Parameters

id
string<uuid>
required

Body

application/json
enabled
boolean
actor
Actor · object

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.

Response

200 - application/json

Success

fold
LineageFold · object

LineageFold shows many similar entities as one node in lineage.

Some tools write to a new table or a new storage path on every run: a date sharded table (events_20261008), a staging table per load (tmp_load_<uuid>), an export per day (exports/orders_20261008). Each of them is its own entity, so lineage shows one node per day or per run. A fold matches those entities and lineage shows them as the single fold node instead, connected to everything any of them is connected to.

Folding changes only how lineage is drawn. Every folded entity keeps its own page, checks, owners and documentation, and switching a fold off brings the original nodes back.