ServiceUserRole

A ServiceUserRole is a bundle of permissions you grant to an end-user who signed up for your product, that is, a ServiceUser. It holds in one resource what they can do (read, create, edit, delete, publish) to Content Types, Content, and Media, along with filters that narrow the scope, such as only certain Content Types or only what they created. These permissions apply to the ACMA/ACDA that the ServiceUser calls.

It sits in a different place from a SpaceRole. A SpaceRole is a bundle of permissions for a Weegloo User (a content studio user) and applies to CMA/CDA, while a ServiceUserRole is a bundle of permissions for a ServiceUser who signed up for your product and applies to ACMA/ACDA. A ServiceUserRole you create applies to nobody on its own. You grant it by setting it as the default role (defaultRole) on a ServiceLogin, or by binding it to the roleOverride of a ServiceUser.

Resource structure

The following is the single-read response for the ServiceUserRole "Buyer". Together with sys (system properties), it has the body properties that define permissions: contentType, content, and media.

{
  "sys": {
    "id": "3trmXRLXeZN2RTHvVj3hFDN5546vbp",
    "type": "ServiceUserRole",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T12:40:36.944Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T12:40:36.944Z",
    "version": 1
  },
  "name": "Buyer",
  "description": "Member who can read published products",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRM3RqbgSnifyg7PAmlxvX4fGY", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } }
}

Key properties:

• contentType: The permission map for Content Types themselves (the schema). It defines, per action, the permission to read, create, edit, delete, and publish a Content Type.
• content: The permission map for Content (the content data). The example above limits the role to reading only the Content of one specific Content Type.
• media: The permission map for Media (files and images).

Unlike a SpaceRole, a ServiceUserRole has no settings to hold access to Space settings, because a ServiceUser does not work with Space settings. It also has no sys.isLocked to mark whether the role is provided by default.

System properties (sys)

Every ServiceUserRole carries common system properties in the sys object. space, createdBy, and updatedBy are in the Refer shape ({ "sys": { "id", "type": "Refer", "targetType" } }).

A ServiceUserRole is a settings resource with no publishing concept. So unlike Content and Media, its sys has no publish, archive, or status, only version. The version increases each time you update the ServiceUserRole. Unlike a SpaceRole, it also has no sys.isLocked.

Permission maps: contentType, content, media

contentType, content, and media are each a map keyed by action. The actions are Read, Create, Edit, Delete, and Publish, plus All, which refers to every action at once. The value of each action is an object holding Allow and Deny arrays of rules. This permission-map structure is the same as a SpaceRole.

"content": {
  "Read":   { "Allow": [ /* rule */ ], "Deny": [ /* rule */ ] },
  "Edit":   { "Allow": [ /* rule */ ] }
}

Each rule object has optional filters that narrow the permission's scope.

• contentType: Limits the target the rule applies to a single specific Content Type. You put in a Refer that points to a Content Type.
• createdBy: Limits to only resources created by a specific user. Put a specific user id in sys.id to limit to what that person created, or the reserved value :self to limit to "only what the ServiceUser making the current call created".
• tag: Limits to only resources carrying a specific Tag.

An empty Allow array [] means the action is allowed across the entire kind. Because the filter is empty there is nothing to filter out, so the action is open to all resources.

Unlike a SpaceRole, a ServiceUserRole has no settings. The permission maps are only the three: contentType, content, and media. For how to write the permission maps, including the action list, the filter keys, and the meaning of :self, see also the explanation in SpaceRole, which uses the same structure. The update block below shows an example that uses :self to narrow editing to only the Content the caller created.

The action list (Read, Create, Edit, Delete, Publish, All), the filter keys (contentType, createdBy, tag), and the meaning of :self follow the weegloo-space-role permission-rule definition. For a ServiceUserRole, :self resolves to only what the current ServiceUser created.

API

The base URL for all endpoints below is https://cma.weegloo.com/v1, and a Bearer token that authenticates against CMA is required in the Authorization header. Role updates (PUT, PATCH) must also send the X-Weegloo-Version header (the current resource's sys.version) for optimistic concurrency control. Create and delete do not have this header.

Related documents

• ServiceUser: The signed-up member who receives this role (roleOverride).
• ServiceLogin: Set a ServiceUserRole as the default role (defaultRole).
• SpaceRole: The permission bundle for Weegloo Users (same permission-map structure).