ServiceUser

A ServiceUser is an end-user of your product who signed up through ServiceLogin, that is, a member account. It is a separate identity from a Weegloo platform account (the Weegloo User who logs in to the content studio), and a ServiceUser's token authenticates against ACMA/ACDA.

A ServiceUser is created when a member signs up directly through ServiceLogin. For that reason this API has no create endpoint, only reads and a few updates made by an administrator (a Weegloo User).

Resource structure

The following is the single-read response for one ServiceUser. Together with sys (system properties), it has the body properties that hold the member's display info and permission settings: nickname, avatarUrl, roleOverride, and enableLogin.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSusr01Ex",
    "type": "ServiceUser",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "buyer@example.com",
    "createdAt": "2026-06-18T12:50:00.000Z",
    "updatedAt": "2026-06-18T12:50:00.000Z"
  },
  "nickname": "Regular shopper",
  "avatarUrl": "https://lh3.example.com/a/buyer-avatar",
  "roleOverride": null,
  "enableLogin": true
}

Key properties:

• sys.email: The email address the member used to sign up. Together with sys.provider, it shows which account they signed up with.
• sys.provider: The OAuth provider used to sign up (for example, google).
• roleOverride: The Refer you put in to give a different ServiceUserRole to this member alone. When it is empty (null), the member follows ServiceLogin's default role.

System properties (sys)

Every ServiceUser carries common system properties in the sys object. space is in the Refer shape ({ "sys": { "id", "type": "Refer", "targetType" } }).

Because a ServiceUser is a resource a member creates by their own sign-up, its sys has no createdBy, updatedBy, or version, unlike other CMA resources. Since there is no version, updates (PUT, PATCH) also do not send the X-Weegloo-Version header. There is no publishing concept either, so there is no publish, archive, or status.

Body properties

Managing members

A ServiceUser comes into being through sign-up. An administrator (a Weegloo User) can adjust the following two things with an update (PUT, PATCH).

• Set/clear roleOverride: Gives a different ServiceUserRole to one specific member only. Use it when you want to treat a single member differently, such as for a paid tier, a moderator, or a beta group. A roleOverride you set takes precedence over ServiceLogin's defaultRole.
• Toggle enableLogin: Turning it off blocks that member's login.

Removing a member from the roster is done in the content studio. The steps, and what goes with them, are covered in Managing service members.

To let one member handle resources created by other members, build a separate ServiceUserRole that carries that permission and set it on that member's roleOverride. What a member can reach is decided by the ServiceUserRole applied to them. When a rule's createdBy filter is set to :self, that action targets only what the member created themselves; when the filter is left out, the action targets what other members created as well. Building the two roles separately is covered in ServiceUserRole.

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. Because a ServiceUser is a resource with no version, updates (PUT, PATCH) also do not send the X-Weegloo-Version header. There is no create endpoint (a member is created by sign-up).

When you filter the list read by sys.email, use exact-match operators only (eq, ne, in, nin). A member's address is stored encrypted, so on that representation you can only decide whether it is equal or not; prefix and the comparison operators return 0 results without an error. If you looked a member up by address and the result is empty, check the operator first. A search by part of an address cannot be done with this filter.

Related documents

• ServiceUserRole: The permission bundle to give to roleOverride.
• ServiceLogin: Member sign-up and default-role (defaultRole) settings.
• ACMA/ACDA overview: The API a ServiceUser calls.
• Reading the member directory in a Script: How to look a member up by id or email inside a Script, and the limits on it.