System properties (sys)

Every resource response in WEEGLOO splits into two parts. One part is the resource's own body data, such as fields; the other is the metadata managed by the system. All of that metadata lives in the sys object.

sys carries the resource's identifier (id), kind (type), creation and update times, version, and relationships to other resources. This page gathers in one place the structure of sys that every resource shares, along with the differences per resource kind. Each individual resource reference describes only its own resource-specific sys keys and refers back to this page for the common parts.

Common fields

Almost every resource's sys has the following fields. createdBy, updatedBy, and space come in the Refer shape that points to another resource ({ "sys": { "id", "type": "Refer", "targetType" } }). The detailed shape is covered in The Refer shape below.

version is also used to prevent concurrent-edit conflicts. Change-type requests such as update and publish must carry the current version value in the X-Weegloo-Version header. For the detailed rules, see Conventions.

An Organization is not a sub-resource of a Space, so it does not have space. Instead it has plan (Refer<Plan>), which points to the plan it belongs to, and isOfficial (boolean), which indicates whether it is official. A Space has organization (Refer<Organization>), which points to its parent Organization, and plan.

The Refer shape

A reference that points to another resource from within sys always uses the same shape. type is fixed to "Refer", and targetType tells you the kind of resource being pointed to.

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

targetType holds the name of the kind of resource being pointed to. For example, space has a targetType of "Space", createdBy and updatedBy have "User", and Content's contentType has "ContentType". In other words, every type written as Refer<User> or Refer<Space> uses this same shape, and only targetType differs.

Differences per resource kind

On top of the common fields, additional properties are attached depending on the resource kind. They fall into three broad groups.

Publish-lifecycle resources (Content, Media)

Content and Media have a lifecycle of authoring, publishing, and archiving. Because of that, properties representing the publish state are added to sys.

status is one of the following four values.

The publish object is a pointer to the publish state. While published, it has all of the following keys.

When you unpublish, version, at, and by are removed from publish, leaving only firstAt and counter. If it has never been published, publish is { "counter": 0 }.

The archive object is present only while archived; it has version (at the time of archiving), at (the archive time), and by (the user who archived it). When not archived, the archive key itself is absent.

Here, sys.version is the working version (it increases with every change, such as create, update, and publish), while publish.version is the version that was last published. The two can differ.

The following is an example of the sys of a published Content.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "tcq4V2Xb", "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"
}

The order of state transitions in the publish lifecycle and the response at each step are covered in Content and Media.

Configuration resources (Tag, Locale, Organization, Space, and so on)

Resources such as Tag, Locale, Organization, Space, SpaceRole, ServiceUserRole, Webhook, and ServiceLogin have no concept of publishing. Once you create them, they apply immediately, and there is no step of publishing them onto a delivery path.

So their sys has no status, publish, or archive, and along with the common fields it has only version. version increases by 1 each time you update, and you carry it in the X-Weegloo-Version header on change requests.

A SpaceRole additionally has isLocked (boolean). When it is true, it means the role is one that WEEGLOO provides by default.

Special resources (ServiceUser, WebHosting)

Some resources have a sys that does not fit either of the two groups above.

A ServiceUser is a resource created by sign-up on the product. It is not a resource that a person creates and edits in the content studio, so its sys has no createdBy, updatedBy, or version. Instead it has provider (string), the login method, and email (string). Because it has no version, you do not need the X-Weegloo-Version header when updating a ServiceUser.

A WebHosting is a resource that hosts a deployment. It has the common fields and version, and to those is added state (enum), the deployment processing status. This is not a publish status but the progress status of processing an uploaded deployment.

The difference between CMA and CDA: version vs revision

Even for the same Content or Media, the shape of sys differs depending on which API you receive it from.

The Content and Media you receive from CMA (management) are working resources. So they carry version, status, publish (and archive if archived) all together, telling you both the current working state and the publish state.

CDA (delivery) delivers only the published snapshot. There is no concept of a working state, so its sys does not carry version, status, publish, or archive. Instead it uses a single revision (integer), which points to the number of the published snapshot. revision is set to the version at the time of each publish.

{
  "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
  "type": "Content",
  "space": { "sys": { "id": "tcq4V2Xb", "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
}

The publish-delivery model (only published resources are delivered, the publish snapshot, and revision) is covered in detail in CDA overview.

Related documents

• Common query parameters: List reads and pagination.
• Conventions: Media type, JSON Patch, concurrency (X-Weegloo-Version).
• Errors: The error response format and common codes.
• CDA overview: The publish-snapshot (revision) delivery model.