ACMA (App Content Management API)

Última actualización: 22 de junio de 2026

ACMA (App Content Management API) es la API con la que los miembros registrados en el producto, es decir los ServiceUser, manejan directamente Content y Media. Se puede entender como las mismas operaciones que un Weegloo User realiza sobre el contenido mediante CMA, pero ejecutadas con la identidad del miembro. El miembro crea (Create), lee (Read), modifica (Update) y elimina (Delete) Content y Media a través de ACMA. El alcance permitido de cada operación lo define el ServiceUserRole.

Las llamadas a ACMA usan el Bearer token emitido por ServiceLogin. Este token solo es válido en ACMA y ACDA, y no puede usarse en CMA ni CDA (para el flujo de emisión del token, consulte Auth API). El Content Type, que es el molde que siguen los miembros, no se crea ni se modifica en ACMA. El Content Type lo gestiona un Weegloo User en CMA, y ACMA no tiene endpoints de creación ni modificación de Content Type.

En qué se diferencia de CMA

ACMA se corresponde con CMA, pero difiere en identidad, alcance de propiedad y comportamiento de publicación.

AspectoACMA (ServiceUser)CMA (Weegloo User)
IdentidadServiceUser registrado en ServiceLogin. Los permisos los define el ServiceUserRole.Weegloo User. Los permisos los define el SpaceRole.
Alcance de accesoEl alcance de lectura, modificación y eliminación lo define el ServiceUserRole (del mismo modo que la lectura por miembro de ACDA). Si en las reglas del rol se fija createdBy como :self, esa operación queda limitada a los datos creados por uno mismo, y normalmente se aplica así a la modificación y la eliminación. La lectura puede abarcar también datos de otros miembros en la medida en que el rol lo permita.Maneja los datos de todo el Space dentro del alcance que permite el SpaceRole.
Publicación al crearAl crear Content o Media se publican de inmediato. No hay una llamada de publicación aparte.El Content requiere una llamada de publicación aparte tras crearse para entrar en la ruta de entrega.
Publicación al eliminarAl eliminar, la anulación de publicación ocurre automáticamente junto con la eliminación. No es necesario anular la publicación antes.Los datos en estado publicado se anulan de publicación primero y normalmente se eliminan después.
Perfil propioSe consulta con GET /me (no con /spaces/{spaceId}/me).GET /me (el Weegloo User actual).
Content TypeNo tiene endpoints de creación ni modificación. El molde es competencia de CMA.Crea, modifica y publica Content Type.

Un miembro cuyo ServiceUser.isAdmin sea true puede hacer además únicamente eliminar los datos de otros miembros. Es un permiso que se añade por encima de las operaciones que el rol permite, y no implica que aumenten los permisos de modificación ni de lectura sobre los datos de otros miembros. E incluso eso solo es posible dentro del alcance de operaciones que permita el ServiceUserRole de ese miembro.

Para una explicación detallada de los comportamientos anteriores (alcance de propiedad, publicación automática al crear, anulación automática de publicación al eliminar, alcance de isAdmin), consulte Inicio de sesión de ServiceUser (concepto).

Mi información (Me)

GET /me devuelve la información del propio ServiceUser del token actual. Como en CMA, no se pasa por la ruta del Space, sino que se llama directamente a /me.

A continuación se muestra la estructura de respuesta de un ServiceUser. En sys se incluye la identidad y la información de registro, y en el cuerpo se incluyen propiedades de visualización como nickname y avatarUrl.

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

Claves principales:

  • sys.id: identificador único del ServiceUser. El createdBy del Content y Media que crea el miembro apunta a este valor.
  • sys.type: tipo de recurso; para ServiceUser siempre es "ServiceUser".
  • sys.space: referencia que apunta al Space al que pertenece este miembro.
  • sys.provider: proveedor usado para el inicio de sesión (por ejemplo, google).
  • sys.email: dirección de correo proporcionada por el proveedor de inicio de sesión.
  • nickname: nombre de visualización del miembro (obligatorio).
  • avatarUrl: dirección de la imagen de perfil (opcional).
  • roleOverride: referencia que apunta al rol cuando se aplica un ServiceUserRole distinto solo a este miembro (opcional). Si no se establece, sigue el rol predeterminado de ServiceLogin.
  • enableLogin: indica si se permite el inicio de sesión.
  • isAdmin: si es true, puede eliminar los datos de otros miembros (consulte En qué se diferencia de CMA arriba).

Solo se pueden modificar nickname y avatarUrl. Valores como provider, email o isAdmin no los cambia el miembro directamente.

Content

Content es un dato individual que sigue un molde llamado Content Type. En el caso de una tienda de ropa en línea, cada producto que sigue el Content Type "Producto" es un Content. En ACMA el miembro maneja su propio Content mediante la ruta vinculada al Space y al Content Type (/spaces/{spaceId}/content-types/{contentTypeId}/contents).

A continuación se muestra un Content "Producto" del Space de demostración.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGhwhlqvAvq",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 3,
      "at": "2026-06-16T14:35:11.210Z",
      "firstAt": "2026-06-15T15:16:20.180Z",
      "counter": 3,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:16:12.151Z",
    "updatedAt": "2026-06-16T14:35:11.210Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 4,
    "status": "Published"
  },
  "fields": {
    "price": { "ko-KR": 18000 },
    "description": { "ko-KR": "이중 진공 단열로 보온·보냉이 오래갑니다. 500ml 대용량." },
    "photo": {},
    "productName": { "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

Claves principales:

  • sys.id: identificador único del Content. Va en el {contentId} de las rutas de consulta individual, modificación y eliminación.
  • sys.contentType: referencia que apunta al Content Type que sigue este Content.
  • sys.status: estado de publicación. El Content creado en ACMA se publica de inmediato y se devuelve como Published.
  • sys.version: versión del recurso; aumenta en 1 con cada cambio.
  • sys.publish: historial de publicación (version, at, firstAt, counter, by).
  • fields: contiene el valor de cada campo en la forma { apiName: { locale: value } }. El ejemplo anterior contiene price, description, photo y productName en la locale ko-KR. Un campo sin valor (photo) es un objeto vacío.
  • metadata.tags: lista de Tag asociados a este Content.

La consulta de lista admite los parámetros de consulta estándar (limit, skip, next, prev, order, select, include), y la respuesta devuelve un arreglo items junto con links (cursores de página).

Media

Media es un activo de archivo subido (imágenes, videos, documentos, etc.). Para que un miembro cree un Media, primero sube el archivo con la Upload API y obtiene un Upload, y luego incluye el sys.id de ese Upload en la solicitud de creación del Media. El Media también se publica automáticamente al crearse en ACMA.

A continuación se muestra el Media de la foto del termo subido al Space de demostración.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7OGjUMsPV3uU",
    "type": "Media",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-15T15:17:30.825Z",
      "firstAt": "2026-06-15T15:17:30.825Z",
      "counter": 1,
      "by": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } }
    },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "createdAt": "2026-06-15T15:17:30.589Z",
    "updatedAt": "2026-06-15T15:17:30.825Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PSrUm9k2BaZ", "type": "Refer", "targetType": "ServiceUser" } },
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "ko-KR": "스테인리스 텀블러 500ml 정면 컷" },
    "description": { "ko-KR": "흰 배경에서 찍은 텀블러 정면 제품 사진입니다." },
    "file": {
      "ko-KR": {
        "fileName": "tumbler.png",
        "contentType": "image/png",
        "mimeGroups": ["Image"],
        "url": "https://weegloo-media.com/medias/HnQ32YiH/3uU/3trmXRM3RqbgSnifyg7OGjUMsPV3uU/ko-KR/1/tumbler.png",
        "detail": { "size": 50847, "image": { "width": 900, "height": 900 } }
      }
    }
  },
  "metadata": { "tags": [] }
}

Claves principales:

  • sys.id: identificador único del Media. Va en el {mediaId} de las rutas de consulta individual y eliminación, y es el valor al que apunta un Content cuando referencia la foto.
  • sys.status: estado de publicación. El Media creado en ACMA se publica de inmediato y se devuelve como Published.
  • fields.title, fields.description: contienen el título y la descripción del activo como mapa por locale (opcional).
  • fields.file: información del archivo por locale (obligatorio). Cuando termina el procesamiento, se rellenan url (dirección de entrega), mimeGroups y detail (tamaño, resolución de la imagen, etc.).

En el fields.file de la solicitud de creación de Media se incluye la referencia al Upload en estado previo al procesamiento. Cada entrada de archivo incluye fileName, contentType, mimeGroups, state y upload; state es siempre "PENDING" y en upload se pone el sys.id del Upload obtenido con la Upload API. Justo después de la creación, la plataforma procesa el archivo y, cuando termina el procesamiento, se rellenan url y detail como en la respuesta anterior.