Media

A Media is a resource that holds an uploaded file. Each individual file, such as an image or a document, is managed as one Media. Take a clothing store as an example: the product photo "Stainless Tumbler 500ml side shot" is one Media.

A Media is managed separately from Content. A Content points to a Media through a Refer type field (e.g. a product's "main photo") to use that file. In CMA, a Media is a sub-resource of Space, and its path is based on /spaces/{spaceId}/medias. Management operations are performed on CMA, and a published Media is delivered to the outside through a delivery URL.

Resource structure

The following is the single-read response for the published Media "Stainless Tumbler 500ml side shot". Along with sys (system properties), it has fields (field values) and metadata (additional information such as tags).

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PBe7ehkOn8e",
    "type": "Media",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T10:11:46.712Z",
      "firstAt": "2026-06-18T10:11:46.712Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T10:11:46.586Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T10:11:46.712Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "title": { "en-US": "Stainless Tumbler 500ml side shot" },
    "description": { "en-US": "Side 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, update, delete, and publish paths.
• fields: The field values of the Media. They consist of three keys, title, description, and file, whose detailed shape is explained in File structure (file) below.
• metadata.tags: The list of Tags attached to this Media. Each entry is in the Refer<Tag> shape, and it is an empty array [] if no tags are attached.

Unlike a Content, a Media has no contentType. Without a template that defines its field composition, every Media has the same title, description, and file structure.

File structure (file)

fields consists of three keys, title, description, and file, each of which is a per-locale map. title and description map a Locale key to a string value, while file maps a Locale key to a file object. As in the example above, the demo Media has a value under the single en-US key.

The file object of a Media whose processing has finished has the following keys.

mimeGroups is the value that groups a file into logical categories. It holds one or more of the following.

Attachment, Plaintext, Image, Audio, Video, RichText, Presentation, Spreadsheet, PdfDocument, Archive, Code, Markup.

The shape of the file object while processing

An uploaded file is not delivered right away just after the Media is created. While the system is processing the file, two more keys are attached to the file object.

• upload: A Refer<Upload> that points to the Upload being processed.
• state: The processing state. It is one of the values below.

When processing finishes, upload and state are removed, and url and detail are filled in instead. In other words, if there is no state key and url is present, that file is ready to be delivered.

System properties (sys)

Every Media carries common system properties in the sys object. space, createdBy, and updatedBy are in the Refer shape ({ "sys": { "id", "type": "Refer", "targetType" } }).

Unlike a Content, a Media has no contentType property, because it does not follow a template.

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. While archived it has version (the sys.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.

The sys.version and all the time values in the examples below are the values at the actual call time, and they differ from call to call.

Upload and publishing lifecycle

A Media is created by first uploading a file and then referencing the result.

1. Upload a file through the Upload API to get one Upload.
2. Create a Media with POST /medias, referencing that Upload. Just after creation, status is Draft and the file's state is PENDING.
3. When the system finishes processing the file, it automatically changes the Media to Published. At that point the file becomes ready to be delivered.

If you pass the X-Weegloo-Ignore-Publish: true header on the POST request, automatic publishing is skipped and it is left as Draft. Updates and partial updates are also automatically published again by default once processing finishes, and the same header can turn that off.

Update, partial update, publish, unpublish, archive, and unarchive requests must carry the current sys.version in the x-weegloo-version header. If this value is missing or does not match the current version, it is treated as a concurrent-edit conflict and the request is rejected. Create and delete requests do not carry this header. State transitions such as publish, unpublish, archive, and unarchive have no separate request body.

Archive and delete cannot be done directly from a published state. You must unpublish first. Trying to archive a published Media is rejected with WGL422007, and trying to delete it is rejected with WGL422009.

API

The base URL for all endpoints below is https://cma.weegloo.com/v1, and a Bearer token that authenticates against CMA is required in the Authorization header. Update, partial update, publish, unpublish, archive, and unarchive must also send the X-Weegloo-Version header (the current resource's sys.version) for optimistic concurrency control.

Related documents

• Upload API: The request that uploads a file to get an Upload to use when creating a Media.
• Content: The body data that points to and uses a Media through a Refer field.
• Tag: The classification labels attached in metadata.tags.