Process Integration/API PUT or POST to add Configuration Item?

The API documentation leads one to believe that it's possible to add configuration items by id to a ticket at creation or by updating, but I can't seem to make it work.

We're working on an inventory clean up and need to generate dozens of tickets over the course of several weeks to track the work. I need to be able to attach the related computers to the tickets. 

I definitely don't want to have to generate each ticket by hand, searching for and selecting each individual computer to relate it to the ticket, when I have CSV files I've generated with all the data required to plug into automated tickets.

I don't care if it's JSON or XML, I'd just like to not do this manually.

  • API request body to PUT a single asset to an incident via the API or a process integration:


    "incident": {
    "assets": {"id": "#assetID"}
    The process integration works just fine if a SW hardware ID is input as a custom field and the {{}} variable used. 
  • Hey B Johnson, any way you can share a screenshot of what your process integration looks like? Just curious.

  • Sorry, the image insertion function here is terrible. I have a "SW ID" custom input field for the form. Here's the text of what's set:


    HTTP Method
    Retries* 1
    <id>{{SW ID}}</id>

    Hope this helps!

  • I'm trying to get this to work also. I keep getting

  • Works for me both on XML or JSON but you have to know the SW ID for each asset. Its not quite simple to do that. I manage to build some manual relationships via custom fields (which i think its overkill if you have lots of assets) for key assets that would translate, in my case, an asset barcode and associate it with an Asset ID to then attach the asset as a related item. Ugh!!. This needs to improve. Here is my code:

  • It would help if i would attach it right? Here we go again. Samanage needs to fix this:

    For XML, just follow XML format.

    The problem i have is that it executes way to fast the way i am doing it since i have it in what i think, is the only way to automate this. I have a custom field with all the known asset tag numbers prefilled with drop down type, then i have a condition as part of the process that populates a field i reference in my code of type drop down as well (Hardware ID). When the process executes it goes way too fast for the API to capture the Hardware ID field and it gives me an error.

    So, what i am doing right now is only reserving this function for known offending devices and building rules to track tickets and relations to the asset. Since i can not expect a user to know their AssetID (what the API considers an asset ID), which is the only way so far that i see i can attach an asset in an automated way, i have field the user can enter (Asset Tag# on their device) that then Samanage translates to a hardware ID (which is the real API asset ID) i designate based on a process condition.

    Its a very manual process and the only way i got around this manual process is to pre-populate the fields with known asset id's and known asset tags and connecting them via process conditions.

    I sort of have to stop the process, say a set a task for a tech to update something on this ticket, then that gives Samanage enough time so that upon task execution from the tech, it then has had enough time to record field data and thus the API will work like a charm and then successfully attach the asset.

    Both of these fields are global fields btw. I think it works best that way instead of a service catalog field.

    See the picture below for more with no task prior to the API:

    If i do not add a stop or a task of some sorts, it fails to update with the following error:

    If i add a stop i get a success but only after i give it a minute or so and then check off the task (which i am using in this example as a pause so to speak):

    Pause task added:

    Pause task checked with related asset added successfully:

  • I like to use postman to test the APIs. You get a lot better detail on the errors n such. I noticed that you aren't using the x-smanage auth bearer token. Maybe you omitted that for security reasons. But here is what Im passing, obviously mine is blurred out.