vManage API /attachfeature returns HTTP 400 – Unable to update device

[Moxa]

Hello everyone, I’m encountering an issue when trying to update device template variables via the vManage REST API.The API consistently returns an HTTP 400 Bad Request, even though the workflow follows Cisco’s documented process and mirrors the web UI “Change Device Values” operation. My goal is to automate template variable updates that are currently performed manually in the UI.

Workflow Attempted:

Step 1 – Authentication
POST /j_security_check and GET /dataservice/client/token → success

Step 2 – Retrieve Device Info
GET /dataservice/device → success

Step 3 – Get Template Info
GET /dataservice/template/device/config/attached/{templateId} → success

Step 4 – Get Current Variables
POST /dataservice/template/device/config/input → success, retrieved full variable list

Step 5 – Update Variables ( Failing )
POST /dataservice/template/device/config/attachfeature → failed, HTTP 400 Bad Request

What I’ve Tried

• Verified isEdited = true

• Confirmed variable names match template fields

• Ensured values are string type

• Compared structure with working iTest automation payloads

• Rechecked JSON against API documentation

Questions

1. Is the payload for /attachfeature missing any required fields or structure?

2. How can I get detailed error information for 400 responses?

3. Is this the right endpoint, or should a detach/attach sequence be used?

4. Does the web UI trigger additional backend calls that need to be replicated?

[Enes Simnica]

ohoy there @Moxa . Let me get my coffee, and try to give u an answer, as short as possible... loool. 

Here we go: A 400 from /attachfeature usually means something in the payload doesn’t fully match what vManage expects, even small differences can cause it. A few things to check: 

• Make sure you’re including deviceTemplateList, isEdited: true, and the full device list with variable JSON, the API expects the entire structure, not just updated variables.
• U can often get more detail by checking the vManage server logs (/var/log/nms/vmanage-server.log) right after the call, they’ll show which field failed validation.
• If updating a single device, some versions of vManage behave better if you detach → reattach instead of using /attachfeature.

and dont forget that the web UI actually triggers the same endpoint but sometimes adds internal IDs or default fields missing from manual API calls. Comparing the browser network trace, when updating via the UI can help spot those differences.

hope it helps and PEACE!

-Enes