ACMA (App Content Management API)

ACMA (App Content Management API) is the API a member who has signed up for your product, that is a ServiceUser, uses to work with Content and Media directly. Think of it as doing the same work a Weegloo User does on CMA, but under a member identity. With ACMA, members create, read, update, and delete Content and Media. The scope allowed for each action is decided by the ServiceUserRole.

ACMA calls use a Bearer token issued by ServiceLogin. This token is valid only on ACMA and ACDA and cannot be used on CMA or CDA (for the token issuance flow, see the Auth API). The Content Type that frames a member's data is not created or modified on ACMA. Content Type is managed by a Weegloo User on CMA, and ACMA has no endpoints for creating or modifying a Content Type.

Differences from CMA

ACMA mirrors CMA, but the identity, ownership scope, and publish behavior differ.

A member whose ServiceUser.isAdmin is true can additionally do only the deletion of other members' data. This is added on top of the actions the role already allows, and it does not increase update or read permissions over other members' data. Even that is possible only within the range of actions allowed by that member's ServiceUserRole.

For a detailed explanation of the behavior above (ownership scope, automatic publish on create, automatic unpublish on delete, and the scope of isAdmin), see ServiceUser login (concept).

Me

GET /me returns the ServiceUser identified by the current token. Unlike CMA, it does not go through a Space path; you call /me directly.

The following is the response structure of a ServiceUser. sys holds the identity and sign-up information, and the body holds display properties such as nickname and avatarUrl.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY",
    "type": "ServiceUser",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "alex.morgan@example.com",
    "createdAt": "2026-06-17T09:12:03.114Z",
    "updatedAt": "2026-06-17T09:12:03.114Z"
  },
  "nickname": "Alex",
  "avatarUrl": "https://lh3.googleusercontent.com/a/example-avatar",
  "enableLogin": true,
  "isAdmin": false
}

Key properties:

• sys.id: The unique identifier of the ServiceUser. The createdBy of the Content and Media a member creates points to this value.
• sys.type: The resource kind. For a ServiceUser this is always "ServiceUser".
• sys.space: A reference pointing to the Space this member belongs to.
• sys.provider: The provider used to sign in (for example, google).
• sys.email: The email address supplied by the login provider.
• nickname: The member's display name (required).
• avatarUrl: The profile image address (optional).
• roleOverride: A reference pointing to a different ServiceUserRole when applying one to this member only (optional). If not set, the member follows ServiceLogin's default role.
• enableLogin: Whether login is allowed.
• isAdmin: If true, the member can delete other members' data (see Differences from CMA above).

Only nickname and avatarUrl can be modified. Values such as provider, email, and isAdmin are not changed by the member directly.

Content

Content is an individual piece of data that follows a frame called a Content Type. For a clothing-store shopping mall, each product that follows the "Product" Content Type is a Content. On ACMA, a member works with their own Content through a path bound to a Space and a Content Type (/spaces/{spaceId}/content-types/{contentTypeId}/contents).

The following is one "Product" Content from a demo Space.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PBUM8Ds0Xvw",
    "type": "Content",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRM3RqbgSnifyg7PAmlxvX4fGY", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 3,
      "at": "2026-06-18T01:46:58.358Z",
      "firstAt": "2026-06-17T16:59:34.772Z",
      "counter": 3,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-17T16:58:56.660Z",
    "updatedAt": "2026-06-18T01:46:58.358Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 4,
    "status": "Published"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "description": { "en-US": "Double-wall vacuum insulation keeps drinks hot or cold for hours. A roomy 500ml." },
    "photo": {},
    "productName": { "en-US": "Stainless Tumbler 500ml" }
  },
  "metadata": { "tags": [] }
}

Key properties:

• sys.id: The unique identifier of the Content. It goes into {contentId} in the single-read, update, and delete paths.
• sys.contentType: A reference pointing to the Content Type this Content follows.
• sys.status: The publish status. Content created on ACMA is published immediately and comes back as Published.
• sys.version: The resource version, which increments by 1 on every change.
• sys.publish: The publish history (version, at, firstAt, counter, by).
• fields: Holds each field's value in the shape { apiName: { locale: value } }. The example above holds price, description, photo, and productName under the en-US locale. A field with no value (photo) is an empty object.
• metadata.tags: The list of Tags attached to this Content.

The list endpoint accepts the standard query parameters (limit, skip, next, prev, order, select, include), and the response returns an items array together with links (page cursors).

Media

Media is an uploaded file asset (an image, video, document, and so on). To create a Media, a member first uploads a file with the Upload API to get an Upload, then puts that Upload's sys.id into the Media create request. Media, too, is published automatically on creation on ACMA.

The following is the tumbler photo Media uploaded to a demo Space.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PBe7ehkOn8e",
    "type": "Media",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-17T17:07:13.400Z",
      "firstAt": "2026-06-17T17:07:13.400Z",
      "counter": 1,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-17T17:07:13.154Z",
    "updatedAt": "2026-06-17T17:07:13.400Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaY", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "en-US": "Stainless Tumbler 500ml front shot" },
    "description": { "en-US": "Front product shot of the tumbler on a white background." },
    "file": {
      "en-US": {
        "fileName": "tumbler.png",
        "contentType": "image/png",
        "mimeGroups": ["Image"],
        "url": "https://weegloo-media.com/medias/tcq4V2Xb/n8e/3trmXRM3RqbgSnifyg7PBe7ehkOn8e/en-US/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

Key properties:

• sys.id: The unique identifier of the Media. It goes into {mediaId} in the single-read and delete paths, and it is the value a Content points to when it references a photo.
• sys.status: The publish status. Media created on ACMA is published immediately and comes back as Published.
• fields.title, fields.description: Hold the asset's title and description as a locale map (optional).
• fields.file: Per-locale file information (required). Once processing finishes, url (the delivery address), mimeGroups, and detail (size, image resolution, and so on) are filled in.

In the fields.file of a Media create request, you put an Upload reference in its pre-processing state. Each file entry includes all of fileName, contentType, mimeGroups, state, and upload, where state is always "PENDING" and upload holds the sys.id of the Upload obtained from the Upload API. Right after creation the platform processes the file, and once processing finishes, url and detail are filled in as in the response above.

Related documents

• Auth API: The OAuth flow for issuing the token used in ACMA calls.
• ACDA: The read API that delivers published content to members.
• ServiceUser login (concept): Configuring ServiceLogin and ServiceUserRole.
• Upload API: Uploading a file before creating a Media.