# 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 {#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](#the-refer-shape) below.

| Property | Type | Description |
|---|---|---|
| `id` | string | Unique resource identifier. It goes into the `{...Id}` slot of the single-read, update, and delete paths. |
| `type` | string | Resource kind. The value is the name of that resource's kind (e.g. `"Content"`, `"Media"`, `"Tag"`). |
| `createdBy` | Refer<User> | The user who created it. |
| `updatedBy` | Refer<User> | The user who last updated it. |
| `createdAt` | string (date-time) | Creation time. |
| `updatedAt` | string (date-time) | Last update time. |
| `version` | integer (≥1) | Current version. It increases by 1 each time the resource is updated. |
| `space` | Refer<Space> | The *Space* this resource belongs to. Only sub-resources of a *Space* have it. |

`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](/api/reference/common/conventions.md).

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 {#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.

```json
{
  "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 {#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) {#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`.

| Property | Type | Description |
|---|---|---|
| `status` | string (enum) | Publish status. One of `Draft`, `Changed`, `Published`, `Archived`. |
| `publish` | object | The publish-state pointer. See the keys below. |
| `archive` | object | Archive information. Present only while archived; otherwise the key is absent. |

`status` is one of the following four values.

| `status` | Meaning |
|---|---|
| `Draft` | Being authored and not yet published. |
| `Changed` | Has been published before, but later changes are not yet published. |
| `Published` | Published with no unpublished changes. |
| `Archived` | Archived. |

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

| Key | Type | Description |
|---|---|---|
| `version` | integer | The `sys.version` at the time of publishing. |
| `at` | string (date-time) | Last publish time. |
| `firstAt` | string (date-time) | First publish time. Preserved even after unpublishing. |
| `counter` | integer | Cumulative publish count. |
| `by` | Refer&lt;User&gt; | The user who last published. |

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*.

```json
{
  "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](/api/reference/cma/content.md) and [Media](/api/reference/cma/media.md).

### Configuration resources (Tag, Locale, Organization, Space, and so on) {#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) {#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.

| `state` | Meaning |
|---|---|
| `PENDING` | Waiting to be processed. |
| `PROCESSING` | Being processed. |
| `COMPLETED` | Processing finished. |
| `FAILED` | Processing failed. |

## The difference between CMA and CDA: version vs revision {#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.

```json
{
  "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](/api/reference/cda.md).

## Related documents {#related-documents}

- [Common query parameters](/api/reference/common/query-parameters.md): List reads and pagination.
- [Conventions](/api/reference/common/conventions.md): Media type, JSON Patch, concurrency (`X-Weegloo-Version`).
- [Errors](/api/reference/common/errors.md): The error response format and common codes.
- [CDA overview](/api/reference/cda.md): The publish-snapshot (`revision`) delivery model.