API: Add Existing Asset to Existing Ticket

Great question, and it’s an easy endpoint to miss.

Assets are attached to a ticket through the ticket's asset list. The endpoint is named for updating that list rather than for adding to it, which is why it is easy to miss when you go looking for an "add asset" route.

Endpoint

POST /api/v1.0/tickets/{TicketId}/assets

The body is a JSON array of asset objects. The array root is required.

[
  { "AssetId": "29ac7042-35ba-4baa-862e-8523fabf4242" }
]

Returns 200 with the ticket's full asset list after the change, so you do not need a follow-up call to confirm the result.

Headers

The array you send becomes the ticket's asset list

The endpoint sets the list to exactly what you post. Any asset already on the ticket that is not in your array is removed from it. The asset record itself is untouched, only the link to the ticket changes.

So the procedure depends on whether the ticket already has assets.

Ticket has no assets yet

Post the new asset on its own.

[
  { "AssetId": "29ac7042-35ba-4baa-862e-8523fabf4242" }
]

Ticket already has assets

Read the current list, then post the existing assets together with the new one.

1. GET /api/v1.0/tickets/{TicketId}/assets
2. Collect each AssetId from Items.
3. POST /api/v1.0/tickets/{TicketId}/assets with those ids plus the new one.

[
  { "AssetId": "3701e978-368a-481f-8276-10a64d37494b" },
  { "AssetId": "29ac7042-35ba-4baa-862e-8523fabf4242" }
]

Two details worth building around:

• When a ticket has no assets, the GET response has ItemCount: 0 and no Items property at all. Treat a missing Items as an empty list.
• Posting a list identical to the current one is a no-op, so retries are safe.

Attaching the asset when you create the ticket

Since you are already creating the ticket through the API, the shorter path is to send the asset in the create call and skip the second request entirely.

POST /api/v1.0/tickets/new

{
  "IssueId": "795b716d-6269-e611-80f1-000c29ab80b0",
  "LocationId": "0f6e3bd2-03f5-e511-a789-005056bb000e",
  "ForId": "83ada6a9-627a-e611-80f3-000c29ab80b0",
  "Assets": [
    { "AssetId": "29ac7042-35ba-4baa-862e-8523fabf4242" }
  ]
}

The assets are linked as part of ticket creation.

What happens when the asset is linked

• The ticket subject is regenerated from the asset model and the issue, for example Dell Latitude 3160 - Sound > No sound. This is the same behavior as attaching an asset in the web UI. If you need a specific subject, set it after the asset is attached using POST /api/v1.0/tickets/{TicketId}/subject.
• Update rules run, exactly as they do for a UI change, so any rules keyed on the ticket's asset or model will evaluate.
• On sites using the newer permissions model, the API user needs permission to work the ticket.

Linking by model or category

If you want the ticket to reference a device type rather than one specific unit, the same endpoint accepts ModelId or CategoryId in place of AssetId.

[
  { "ModelId": "b3eb4d9d-9e88-415f-88ac-37aef28a9a8a" }
]

The resulting link carries the model with no specific unit, and the matching category is filled in for you. Each entry needs at least one of AssetId, ModelId or CategoryId.

Reading what is linked

GET /api/v1.0/tickets/{TicketId}/assets

Each item includes TicketAssetId, AssetId, AssetTag, SerialNumber, ModelId, ModelName, CategoryId and OwnerId.

To remove an asset, post the list without it.