Delivery Access Token

A DeliveryAccessToken is a read-only token used to read published content from the CDA (public delivery). When a website or app's browser fetches published content, it calls the CDA with this token. At issue time it is bound to a single SpaceRole, and that role determines the token's read scope (which Content Types it can read).

In CMA, a DeliveryAccessToken is a sub-resource of Space, and its path is based on /spaces/{spaceId}/delivery-access-tokens. Because this token operates while exposed to the browser (client), the role you bind to it must be a least-privilege role that reads only the Content Types you actually need (see Security: least-privilege binding below). On top of that, if you put the origins allowed to make calls into allowedReferrers, this token cannot be used outside the sites you listed (see Origin notation rules and Referer enforcement).

Resource structure

The following is the response when a DeliveryAccessToken is created. The token value and scope live in sys (system properties), while name, description, and allowedReferrers are body properties.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUGndFQrblq",
    "type": "DeliveryAccessToken",
    "space": { "sys": { "id": "tcq4V2Xb", "type": "Refer", "targetType": "Space" } },
    "user": { "sys": { "id": "3trmXRLdJIqc9GPBbyFYQQw6hf9kGj", "type": "Refer", "targetType": "User" } },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUGnban93rP", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:25:32.624Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUGnban93rP", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:25:32.624Z",
    "accessToken": "DVRATbQ8mX2vK9pLs7Rf1Zt0Nc4Wd6Hg5Ua2Ee9Ck3PoYx8Bj6Hg5Ua2Ee9Ck3Po…",
    "scopes": ["DELIVERY_ACCESS_TOKEN"]
  },
  "allowedReferrers": ["https://shop.example.com"],
  "description": "Read-only delivery token for the clothing store public site",
  "name": "Public website delivery"
}

Key properties:

• sys.id: The unique identifier of the DeliveryAccessToken. It goes into {deliveryAccessTokenId} in the single-read, update, and delete paths.
• sys.accessToken: The secret token value used to call the CDA. The same value is returned on subsequent reads after issuance, so handle it with care (see the security section below).
• sys.scopes: The token's permission scope. A DeliveryAccessToken is always ["DELIVERY_ACCESS_TOKEN"] at issue time.
• sys.user: The dedicated user that is the authority subject of this token. It is created automatically at issue time, and the permissions of the bound SpaceRole are granted to this user. In other words, the token's effective permissions come from this user. It is a different user from the person who actually issued the token (sys.createdBy).
• name: The token name you specify on creation (e.g. Public website delivery).
• description: A description of the token (optional).
• allowedReferrers: The list that restricts which origins may call this token. An empty list applies no restriction. The token in the example above passes only when it is called from the clothing store's public site (https://shop.example.com) (for the notation rules and how the list is checked, see Origin notation rules and Referer enforcement).

The accessToken in the example above is a secret value, so it is replaced with an example string. In reality it is a long, opaque string, and reading it again after issuance returns the same value.

System properties (sys)

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

Body properties:

Security: least-privilege binding

A DeliveryAccessToken calls the CDA while exposed to the browser and to visitors. Because of this, which SpaceRole you bind it to is exactly what defines the token's security boundary.

• In the create request's role, put the sys.id of a least-privilege SpaceRole that reads only the Content Types you need. A read-only role is recommended for public delivery.
• Never bind the Administrator role. Since this token is exposed to the client, binding a role that carries management privileges leaks those privileges externally as-is. Also, do not absentmindedly use the first item in the SpaceRole list; explicitly specify the sys.id of the intended least-privilege role.
• Tie down where this token may be used as well, with allowedReferrers. The bound role determines what you can read with this token, and this list determines where it can be called from. A token that runs in the browser cannot hide its own value, so once you put your public site's origin in the list, a CDA call from outside that site does not pass even if the token value leaks (see Referer enforcement).
• accessToken is a secret value that is returned with the same value on reads after issuance. Inject it safely into the client build, but do not expose it externally as-is.

Status and constraints

The value constraints observed on creation and update.

Rules about binding and permissions:

• The role you bind must actually exist in that Space. Putting the sys.id of a role that is not in that Space gets the creation rejected.
• A caller can bind only a role they themselves hold in that Space. This constraint prevents granting a token higher privileges by binding a role the caller does not have; a create request that breaks it is rejected. However, an administrator of that Space (a holder of the Administrator role) is not subject to this constraint and can bind any role.
• A DeliveryAccessToken is a count-limited resource. Exceeding your current plan's issuance count limit gets the creation rejected. For per-plan limits, see Pricing.
• Issuing and managing (create, read, update, delete) requires SETTING_DELIVERY_ACCESS_TOKEN in the settings of the caller's role. It is a separate action from SETTING_SPACE_ACCESS_TOKEN, which issues a Space Access Token that can also write, so you can grant only the permission to issue delivery tokens and block the issuance of write tokens (see SpaceRole).
• This API is called only with a console login session or a Personal Access Token. An issued DeliveryAccessToken cannot create another DeliveryAccessToken.

Origin notation rules

Each item in allowedReferrers is a string that points to one origin allowed to make calls. Write it in the following shape.

"allowedReferrers": [
  "https://shop.example.com",
  "https://*.shop.example.com",
  "http://localhost:3000"
]

The list holds up to 50 items, and you cannot put the same origin in it twice. Each item must follow these rules.

• Use only https as the scheme. http is allowed only for localhost, 127.0.0.1, and [::1].
• Use a wildcard only as a single leading *. label. You cannot use one in the path.
• Write the host in ASCII. Enter an internationalized domain in Punycode notation.
• The port ranges from 1 to 65535. If you omit it, the scheme's default port applies (443 for https, 80 for http).
• If you write a path, a request passes only when its path is exactly the same. The browser sends the path percent-encoded, so use only ASCII in the path.
• An item that carries user info (user@), a query (?), or a fragment (#) is rejected.

This check applies on all three paths: create, full update, and partial update. If even one item breaks the rules, the list is not saved and the request is rejected, and one offending item is reported in the error reason (see Errors).

Referer enforcement

Once the token is issued, every CDA call you make with it is checked against allowedReferrers to decide whether it passes.

• An empty list applies no restriction. A call from any origin passes.
• If the list holds even one item, the check reads the request's Referer header value. The Origin header is not consulted.
• A request whose Referer header is missing or empty is rejected. The browser sends this header on its own, but for a token to be used where Referer is not sent, such as a build script running on a server or server-side rendering, leave the list empty.
• To pass, the scheme, host, and port of the Referer must all match one item in the list. If that item carries a path, the path must match as well.
• https://*.shop.example.com covers every host that ends in .shop.example.com, such as admin.shop.example.com, and does not cover shop.example.com itself. To allow both, add https://shop.example.com as one more item.
• This check applies to every request you send with this token. It is the same whichever CDA path you call.
• A request that fails the check is rejected with HTTP 403. The code it returns is in Errors below.

Errors

These are the codes you meet when working with a DeliveryAccessToken. For codes that are common to every resource, see common errors.

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. Updating and partially updating a DeliveryAccessToken does not require the X-Weegloo-Version header.

Related documents

• SpaceRole: Defines the role (read scope) to bind to this token.
• CDA overview: The delivery API that reads published content with this token.
• Space Access Token: A token that can also write within one Space (it has the same origin restriction).
• Personal Access Token: A Weegloo User token for servers and CI.