Datamates

Set Datamate Shares

Set the sharing mode and the whole grant set in one call.

Deliberately not split across PATCH /datamates/{id} for the mode and a separate endpoint for the grants: that shape lets a client set restricted and then fail to send the grants, leaving a workspace that claims to be shared and is visible to nobody but its owner. The request schema refuses that combination outright.

Invalidating the cache is not optional. GET /datamates/ is cached per {tenant}:{user_id} with a 300s TTL, and a grant changes what another user may see without touching their own cache key — so without this a new grantee waits up to five minutes to see the workspace, and, worse, a revoked user keeps seeing it for up to five minutes. Note the cache is an in-process singleton: this clears the pod that served the request, so with several replicas the revocation is still eventually consistent within the TTL. That is a known limit, recorded on AI-8822, not an oversight here.

put/datamates/{datamate_id}/shares

Path parameters

datamate_idinteger required

Request body

privacy'private' | 'public' | 'restricted' required

Sharing modes for a workspace.

Deliberately local rather than adding a member to the shared PrivacySetting, which is imported by five resources (datamates, knowledge bases, notebooks, query bookmarks, custom skills). restricted is meaningless for the other four, and widening the shared enum would make it a legal value there.

The two overlapping values keep identical strings, so rows written before this existed, and every cross-file read that compares against PrivacySetting.PUBLIC.value, still work.

Reviewers found this argument was made and then broken in the same diff: four CustomSkill schemas were swapped to this enum, which made restricted a legal value for a resource with no grant table behind it — _visible_to (crud/custom_skills.py) matches owner-or-public only, and custom_skills.privacy has no CHECK, so such a skill would persist and be permanently invisible to everyone but its creator. Custom skills are back on PrivacySetting; keep them there until they implement sharing.

user_idsinteger[]
team_idsinteger[]

Response

Successful Response

datamate_idinteger required
privacy'private' | 'public' | 'restricted' required

Sharing modes for a workspace.

Deliberately local rather than adding a member to the shared PrivacySetting, which is imported by five resources (datamates, knowledge bases, notebooks, query bookmarks, custom skills). restricted is meaningless for the other four, and widening the shared enum would make it a legal value there.

The two overlapping values keep identical strings, so rows written before this existed, and every cross-file read that compares against PrivacySetting.PUBLIC.value, still work.

Reviewers found this argument was made and then broken in the same diff: four CustomSkill schemas were swapped to this enum, which made restricted a legal value for a resource with no grant table behind it — _visible_to (crud/custom_skills.py) matches owner-or-public only, and custom_skills.privacy has no CHECK, so such a skill would persist and be permanently invisible to everyone but its creator. Custom skills are back on PrivacySetting; keep them there until they implement sharing.

user_idsinteger[] required
team_idsinteger[] required

Changes

Changed in 1 of the 55 revisions of this API.1