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 and description 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"]
  },
  "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).

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

(Source: the weegloo-space-access-token and weegloo-delivery-access-token skills, and .claude/rules/weegloo-global-rules.md.)

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 (WGL404001). An incorrect spaceId fails with the same code.
• 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 violation is rejected with WGL422001. 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 (WGL429001). For per-plan limits, see Pricing.
• Issuing and managing (create, read, update, delete) requires the API key settings permission for that Space. A Space Access Token itself cannot create another Space Access Token.

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.