Space Access Token

A Space Access Token is a token that can read and write content within a single Space. It can create, update, and delete content via the CMA, and CDA reads and Upload are also called with this token. At issue time it is bound to a single SpaceRole, and that role determines what the token can do and how far (which Content Types it can handle, and with which actions).

Unlike the read-only Delivery Access Token, this token can also write. But unlike a Personal Access Token, which is tied to the entire user account, it is confined to a single Space and cannot reach Space settings, the organization or account plane, or any other Space. In CMA, a Space Access Token is a sub-resource of Space, and its path is based on /spaces/{spaceId}/space-access-tokens. Whether you place this token on a server or in a public client (for example, anonymous posting) is something you decide to fit your service. Because it is a powerful token with write access, you secure it by narrowing the role you bind to it to match the exposure of the place where the token lives (see Security: binding a role to match its exposure below).

Resource structure

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

{
  "sys": {
    "id": "7WpR4mKq2bTnXfLc8Vd3HsJ9gEyAo",
    "type": "SpaceAccessToken",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "user": { "sys": { "id": "3trmXRLdJIqc9GPBbyFYQQwYT32LnU", "type": "Refer", "targetType": "User" } },
    "createdBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-19T02:15:38.472Z",
    "updatedBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-19T02:15:38.472Z",
    "accessToken": "SPCATq8Lm2vK9pXfR1Zt0Nc4Wd6Hg5Ua2Ee9Ck3PoYx8Bj6Hg5Ua2Ee9Ck3Po…",
    "scopes": ["SPACE_ACCESS_TOKEN"]
  },
  "allowedReferrers": [],
  "description": "Server token for registering and editing clothing store products",
  "name": "Product backend server"
}

Key properties:

• sys.id: The unique identifier of the Space Access Token. It goes into {spaceAccessTokenId} in the single-read, update, and delete paths.
• sys.space: The Space this token belongs to. The token operates only within this one Space.
• sys.accessToken: The secret token value used for API calls. It starts with SPCAT, and the same value is returned on reads after issuance, so handle it with care about exposure (see the security section below).
• sys.scopes: The token's permission scope. A Space Access Token is always ["SPACE_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. Product backend server).
• 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 example above leaves the list empty because the token is called from a server (for the notation rules and how the list is checked, see Origin notation rules and Referer enforcement).

role (the SpaceRole to bind) is an input value sent only in the create request body; it is not included in the response resource. The bound role is granted to the user dedicated to this token (sys.user in the response), so it does not come back as a role field in read responses. 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 that starts with SPCAT, and reading it again after issuance returns the same value.

System properties (sys)

Every Space Access Token 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:

Create-request body-only input:

Security: binding a role to match its exposure

A Space Access Token is a powerful token that can also write. Which SpaceRole you bind it to becomes the boundary of what this token can do, and its security boundary. Whether you place this token on a server or in a public client (for example, anonymous posting) is something you decide to fit your service, and security comes not from "where you hide it" but from narrowing the bound role to match its exposure.

• In the create request's role, put the sys.id of a narrow SpaceRole that allows only the actions its use requires. For a server token used to register products, bind a role that allows only reading and writing the products Content Type; for a public anonymous-posting token, bind a role that allows only create on the posts Content Type. Bind the minimum to match the exposure.
• The more a token is exposed to a public client, the narrower you should scope its role. Allow only as much as you could tolerate if that token leaked. Do not bind the Administrator role or a broad write role to a public token. Also, do not absentmindedly use the first item in the SpaceRole list; explicitly specify the sys.id of the intended narrow role.
• If the token is called from a browser, narrow down the call site as well with allowedReferrers. The bound role determines what you can do with this token, and this list determines where it can be called from (see Referer enforcement).
• For read-only delivery exposed to visitors, a Delivery Access Token with no write access is a better fit. Use a Space Access Token only when you need to write, and narrow its role to match the exposure.
• accessToken is a secret value that is read with the same value even after issuance. Where it does not need to be exposed, do not leave it in plaintext in code, logs, storage, or error messages; if you suspect it has been exposed, delete it to invalidate it and replace it with a new token.

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 nonexistent role 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 Space Access Token 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_SPACE_ACCESS_TOKEN in the settings of the caller's role. It is a separate action from SETTING_DELIVERY_ACCESS_TOKEN, which issues a read-only Delivery Access Token, so you can grant only the permission to issue delivery tokens and block the issuance of this token (see SpaceRole).
• This API is called only with a console login session or a Personal Access Token. A Space Access Token itself cannot create another Space Access Token, and that holds even if you put SETTING_SPACE_ACCESS_TOKEN in the bound role.

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 API 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. For a token to be used where Referer is not sent, such as server-to-server calls, 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 path you call, on CMA or CDA.
• 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 Space Access Token. 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 Space Access Token does not require the X-Weegloo-Version header.

Related documents

• SpaceRole: Defines the role (read and write scope) to bind to this token.
• Delivery Access Token: A read-only delivery token exposed to visitors (for the client).
• Personal Access Token: A Weegloo User token for servers and CI, tied to the entire account.
• Pricing: The per-plan issuance count limit for Space Access Token.