Propiedades del sistema (sys)

Toda respuesta de recurso de WEEGLOO se divide en dos partes. Por un lado están los datos de contenido propios del recurso, como fields, y por otro lado están los metadatos que gestiona el sistema. Todos estos metadatos se alojan en el objeto sys.

sys contiene el identificador del recurso (id), su tipo (type), las fechas de creación y modificación, la versión y la relación con otros recursos. Esta página reúne en un solo lugar la estructura de sys que comparten todos los recursos y las diferencias según el tipo de recurso. Cada referencia de recurso individual describe por separado solo las claves de sys propias de ese recurso y, para la parte común, remite a esta página.

Campos comunes

El sys de casi todos los recursos tiene los siguientes campos. createdBy, updatedBy y space se incluyen con la forma Refer que apunta a otro recurso ({ "sys": { "id", "type": "Refer", "targetType" } }). La forma detallada se trata más abajo en Forma de Refer.

version también sirve para evitar conflictos de modificación simultánea. En las solicitudes de la familia de cambios, como modificar o publicar, hay que enviar el valor actual de version en la cabecera X-Weegloo-Version. Para las reglas detalladas, consulta Convenciones.

Organization no está subordinada a un Space, por lo que no tiene space. En su lugar tiene plan (Refer<Plan>), que apunta al plan al que pertenece, e isOfficial (boolean), que indica si es oficial. Space tiene organization (Refer<Organization>), que apunta a la Organization superior, y plan.

Forma de Refer

Dentro de sys, las referencias que apuntan a otro recurso usan siempre la misma forma. type queda fijado en "Refer" y targetType indica el tipo de recurso al que apunta.

{
  "sys": {
    "id": "HnQ32YiH",
    "type": "Refer",
    "targetType": "Space"
  }
}

En targetType se coloca el nombre del tipo de recurso al que apunta. Por ejemplo, en space el targetType es "Space"; en createdBy y updatedBy es "User"; y en el contentType de Content es "ContentType". Es decir, todos los tipos que se escriben como Refer<User> o Refer<Space> tienen esta forma, y solo cambia targetType.

Diferencias según el tipo de recurso

Sobre los campos comunes se añaden propiedades adicionales según el tipo de recurso. Se dividen a grandes rasgos en tres grupos.

Recursos con ciclo de vida de publicación (Content, Media)

Content y Media tienen un ciclo de vida de redacción, publicación y archivado. Por eso a su sys se le añaden propiedades que indican el estado de publicación.

status es uno de los 4 valores siguientes.

El objeto publish es un puntero que indica el estado de publicación. Cuando está publicado, tiene todas las siguientes claves.

Al despublicar, de publish se eliminan version, at y by, y solo quedan firstAt y counter. Si nunca se ha publicado, publish es { "counter": 0 }.

El objeto archive existe solo cuando está archivado, y tiene el version del momento del archivado, la fecha de archivado at y el usuario que lo archivó by. Si no está en estado archivado, la clave archive no aparece en absoluto.

Aquí sys.version es la versión de trabajo (aumenta con cada cambio: creación, modificación, publicación, etc.) y publish.version es la última versión publicada. Las dos pueden ser distintas.

A continuación se muestra un ejemplo del sys de un Content que está publicado.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
  "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
  "publish": {
    "version": 1,
    "at": "2026-06-18T09:51:44.128Z",
    "firstAt": "2026-06-18T09:51:44.128Z",
    "counter": 1,
    "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
  },
  "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "createdAt": "2026-06-18T09:51:14.597Z",
  "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "updatedAt": "2026-06-18T09:51:44.128Z",
  "version": 2,
  "status": "Published"
}

El orden de las transiciones de estado del ciclo de vida de publicación y la respuesta de cada etapa se tratan en Content y Media.

Recursos de configuración (Tag, Locale, Organization, Space, etc.)

Recursos como Tag, Locale, Organization, Space, SpaceRole, ServiceUserRole, Webhook y ServiceLogin no tienen el concepto de publicación. Se aplican en cuanto se crean, sin una etapa de publicarlos para subirlos a la ruta de entrega.

Por tanto, su sys no tiene status, publish ni archive, y junto con los campos comunes solo tiene version. version aumenta en 1 cada vez que se modifica, y se envía en la cabecera X-Weegloo-Version al solicitar un cambio.

SpaceRole, además, tiene isLocked (boolean). Si es true, significa que es un rol que WEEGLOO ofrece de forma predeterminada.

Recursos especiales (ServiceUser, WebHosting)

Algunos recursos tienen un sys que no encaja en los dos grupos anteriores.

ServiceUser es un recurso que se genera con el registro de un miembro del producto. Como no es un recurso que una persona cree y modifique en el estudio de contenidos, su sys no tiene createdBy, updatedBy ni version. En su lugar tiene el medio de inicio de sesión provider (string) y email (string). Como no tiene version, al modificar un ServiceUser no hace falta la cabecera X-Weegloo-Version.

WebHosting es un recurso que aloja un artefacto de despliegue. Tiene los campos comunes y version, y a ello se le añade el estado de procesamiento del despliegue state (enum). Este no es un estado de publicación, sino el estado de avance del procesamiento del artefacto de despliegue subido.

Diferencia entre CMA y CDA: version frente a revision

Aunque se trate del mismo Content o Media, la forma de sys es distinta según de qué API se reciba.

El Content o Media que se recibe en CMA (gestión) es un recurso en trabajo. Por eso incluye version, status y publish (y archive si está archivado), e informa a la vez del estado de trabajo actual y del estado de publicación.

CDA (entrega) solo entrega la instantánea publicada. Como no existe el concepto de estado de trabajo, en sys no incluye version, status, publish ni archive. En su lugar usa un único revision (integer) que apunta al número de la instantánea publicada. En revision se guarda la versión de ese momento cada vez que se publica.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
  "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
  "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "createdAt": "2026-06-18T09:51:14.597Z",
  "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
  "updatedAt": "2026-06-18T09:51:44.128Z",
  "revision": 3
}

El modelo de entrega de publicación (solo se entrega lo publicado, instantánea de publicación, revision) se trata en detalle en Resumen de CDA.

Documentos relacionados

• Parámetros de consulta comunes: consulta de listas y paginación.
• Convenciones: tipo de medio, JSON Patch, concurrencia (X-Weegloo-Version).
• Errores: formato de respuesta de error y códigos comunes.
• Resumen de CDA: modelo de entrega de instantáneas de publicación (revision).