Datamates

Get Datamate Shares

Changed on

Who this workspace is shared with. Owner only — the grantee list is the owner's information, not something every viewer should enumerate.

Returns only grantees that actually confer access: a grant row can outlive its subject (subject_id has no foreign key, because it points at two parent tables), so an inactive user or a deleted team is filtered out here exactly as the visibility predicate filters it. Otherwise the UI would offer a "remove" button for access nobody has.

get/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

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