401 "unable to verify user credentials and/or request signature" when calling deleteAutoScaleVmGroup

[bipasaroy10]

Environment

• CloudStack Version: 4.22
• API Response Format: JSON
• Client: Node.js (custom API client using HMAC-SHA1 request
  signing)

Problem

I am able to successfully call several CloudStack APIs using the same
API key, secret key, and signing implementation. For example:

• listAutoScaleVmGroups ✅
• Other read APIs ✅

However, when I call deleteAutoScaleVmGroup, CloudStack consistently
returns the following response:

{
  "success": false,
  "message": "unable to verify user credentials and/or request signature",
  "errors": {
    "errorresponse": {
      "errorcode": 401,
      "errortext": "unable to verify user credentials and/or request signature"
    }
  }
}

What I have verified

• The API key and secret key are correct.
• The same signing logic works for other CloudStack APIs.
• The request is signed immediately before being sent.
• The AutoScale VM Group ID exists and was obtained using
  listAutoScaleVmGroups.
• The id parameter is being passed correctly from the application.

Delete Request

The request is sent using:

command=deleteAutoScaleVmGroup
id=<autoscale_vm_group_id>
response=json

The request is signed using the same helper method that successfully
signs other CloudStack API requests.

Expected Behavior

The AutoScale VM Group should either be deleted successfully or return
an error related to the resource (if applicable), instead of failing
during signature verification.

Actual Behavior

CloudStack returns:

401 - unable to verify user credentials and/or request signature

even though the same credentials and signing implementation work for
other API commands.

Any guidance would be greatly appreciated. Thank you!

[JoaoJandre]

Using the same API key and secret key, can you test calling this API with CloudMonkey (https://github.com/apache/cloudstack-cloudmonkey)?
Also, would you be able to share the code for the API call and signing? Maybe someone can pinpoint the issue easier this way.

[herrickaccuwebhosting]

Interesting one. Since the same signer works for listAutoScaleVmGroups, the signing implementation itself is fine, so this smells more like something specific to how deleteAutoScaleVmGroup builds its parameter set.

A few things worth checking:

Extra params on delete you might not be signing. Some CloudStack delete-type APIs (and definitely some SDKs/wrappers) silently attach extra params like cleanup or forced on delete calls but they don't always get included in both the request AND the signature string consistently. Double check exactly which params are going into the HMAC vs what's on the wire, they need to be identical.
Param case/sorting. CloudStack requires all param keys lowercased and sorted alphabetically before building the string to sign. If your generic signer does this correctly for reads but the delete path constructs the query string through a different code path (custom builder for mutating calls, etc), that divergence is a common source of exactly this kind of "works for GET, fails for this one POST/DELETE" bug.
URL encoding of the signature itself. The base64 HMAC signature needs to be URL-encoded before being appended as the signature param. If your framework auto-encodes params for reads but you're manually building the query string for deletes, it's easy to double-encode or under-encode just that one param.
Definitely do what JoaoJandre suggested and test the same key/secret via CloudMonkey first, that'll confirm in seconds whether it's a credentials/permissions issue vs something in your custom signer specifically for this command.

If you can post the exact param string you're signing (redact the actual id/keys) for both a working call and the failing delete call side by side, that diff usually makes it obvious immediately.

We've built custom API clients against CloudStack here at AccuWeb.Cloud and 9 times out of 10 this exact symptom traces back to one extra or missing param between the signed string and the sent request, so it's worth logging both strings and diffing them byte for byte.