Assets object comments using OAuth 2.0 (3LO) instead of Basic Auth

WELISSON LUIZ DE OLIVEIRA

Hello,

We are developing an internal integration for Jira Service Management Cloud Assets.

Users authenticate through OAuth 2.0 (3LO), and the integration performs Assets operations on behalf of the authenticated user. We need to create comments in the activity section of Assets objects while preserving the user who performed the action as the comment author.

We found references to an Assets comment endpoint similar to:

POST /jsm/assets/workspace/{workspaceId}/v1/comment/create

With a payload similar to:

{
  "objectId": 12345,
  "comment": "<p>Example comment</p>",
  "role": 0
}

However, the public Assets Cloud REST API does not appear to document comment operations for OAuth 2.0 apps. The available granular scopes, such as:

read:cmdb-object:jira
write:cmdb-object:jira

refer to object data and attributes, but do not explicitly mention object comments.

Using Basic Authentication with an API token works through a technical account, but the comment is then attributed to that account instead of the user who initiated the operation. This prevents an accurate per-user audit trail.

Could someone confirm:

1. Is there a supported public endpoint for creating Assets object comments using OAuth 2.0 (3LO)?
2. If supported, what is the correct URL format and required scope?
3. Will the comment be attributed to the user who authorized the OAuth connection?
4. Are reading and deleting those comments also supported through OAuth?
5. If this is not currently supported, is there an existing feature request we can follow and vote on?

Our expected behavior is that the request respects the authenticated user’s Assets schema permissions and records that user as the comment author.

Sami Shaik

@WELISSON LUIZ DE OLIVEIRA
Straight answers to your five questions, because the useful thing here is a boundary you can plan around rather than a workaround you cannot.

1. Is there a supported public endpoint for object comments? No. The Assets Cloud REST API reference has no Comments group. The only documented Assets comment endpoints (/rest/assets/1.0/comment/create, /comment/object/{objectId}) are Data Center, and that page itself says Forge and OAuth 2.0 apps cannot access the resource. The .../v1/comment/create path you found on Cloud is what the Assets UI calls; Atlassian's KB describes that family of paths as internal and states that only the official API is supported. It works with Basic auth today because the API token inherits the user's session-level access, not because it is a contract.

2. What URL and scope? There is no scope. The 3LO and Forge scope list for Assets covers objects, schemas, types, attributes, icons and configuration; nothing covers comments, which is consistent with point 1. A 3LO token will be refused on that path with a scope error, and no combination of the granted scopes changes that.

3. Attribution to the authorising user? Only through the internal path with Basic auth, where the comment's actor is the API token's owner; that is the behaviour you are already seeing (the technical account). Through 3LO it cannot happen, because the endpoint is not reachable at all.

4. Read and delete? Same boundary. The internal read and delete paths exist for the UI; none is public on Cloud.

5. What to do instead, in order of how well it holds up:

• If the comment is about a request, put it on the request. The Jira Cloud platform comment API (POST /rest/api/3/issue/{key}/comment) is fully supported under 3LO with write:jira-work, and it is attributed to the authorising user. If the object is linked to the request through an Assets field, the object's Connected tickets view already surfaces that request, so the audit trail exists without a comment on the object.
• If you need a note on the object itself, model it as data: an attribute on the object type (a text attribute, or a "Notes" child object type with actor, timestamp and text as attributes) written through write:cmdb-object:jira, with the actor's account ID recorded by your app. Attribution is then yours to display, but it is supported, and it is queryable with AQL, which comments never are.
• If the internal endpoint is the only fit, treat it as unsupported infrastructure: isolate it behind one adapter, pin it to a service account that is clearly labelled in the comment text, and expect it to break without notice.

On the feature request: I could not find an open public ticket for "Assets object comments through the public API" on jira.atlassian.com, so raise one on the JSDCLOUD project via Support, and post it in the Assets category of the developer community so the Assets API team sees the use case with your exact attribution requirement. Verified against the Cloud API reference and the scope list on 30 September 2026.