Datamates

Set Datamate Shares

Changed on

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.

put/datamates/{datamate_id}/shares

Request

  • Base URL: https://api.myaltimate.com (the document declares no server; this is the origin it was published from)
  • URL: https://api.myaltimate.com/datamates/{datamate_id}/shares
  • Auth: one of:
    • HTTP bearer
    • HTTP bearer

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