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, whether they can execute a Script, 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, media, and script.

{
  "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": [] } },
  "script": {}
}

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).
• script: The permission map for Script (declarative backend endpoints). A ServiceUser only executes (Execute) a Script, so you usually set only Execute.

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 you can use are Create, Read, Edit, Delete, Publish, Unpublish, Archive, and Unarchive, plus All, which refers to every action at once. Save means the same as Edit. 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.

• self: Limits the target the rule applies to the resource itself, one single resource. In the contentType map it means one specific Content Type; in the script map, one specific Script.
• contentType: Limits to the Content Type the Content belongs to. 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.

Which filter is valid in which permission map is the same as for a SpaceRole (the contentType map names its target with self, and the content map with contentType), and putting in a filter that does not fit makes saving the role fail. The per-map table is in Permission maps on SpaceRole.

To apply a createdBy filter (including :self) on ACDA, the target Content Type's publishWithAuthor must be true. ACDA evaluates this filter against the sys.createdBy of the publish snapshot, so if publishWithAuthor is left at its default false the snapshot has no author: an Allow rule matches nothing (a member receives their own resources as an empty result), and a Deny rule filters out no one. ACMA (management), on the other hand, evaluates against the sys.createdBy of the draft and is therefore independent of this setting, so the same rule may work on ACMA yet break on ACDA. publishWithAuthor must be turned on before members start posting, and it is not retroactive. See the publishWithAuthor description in Content Type.

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 the four: contentType, content, media, and script. 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 (Create, Read, Edit, Save, Delete, Publish, Unpublish, Archive, Unarchive, All), the filter keys (self, contentType, createdBy, tag), and the meaning of :self follow the permission-rule definition in SpaceRole. For a ServiceUserRole, :self resolves to only what the current ServiceUser created.

script (Script permissions)

script is the permission map for Script; its structure is the same as content and media. However, the only thing a ServiceUser can do to a Script is execute it (authoring, that is create/edit/delete, is CMA / Weegloo-User only). So in a ServiceUserRole the only action you meaningfully use in script is Execute.

To let a signed-up member execute a Script:

"script": {
  "Execute": { "Allow": [] }
}

The rule filters you can use are two: self (one specific Script) and createdBy. contentType and tag are axes that do not attach to Script, so putting them in makes saving the role fail. To let a member execute one specific Script and nothing else, put a self rule pointing at that Script in the Allow of Execute.

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

The structure of Script itself and its execute endpoint are covered in Script resource and endpoints; the full action list is covered in the script permission on SpaceRole.

Errors

These are the codes you meet when working with a ServiceUserRole. For codes that are common to every resource, see common errors.

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).