Introduction

This Amazon MWS error means the server reconstructed your signature input and got a different result from the signature you sent. In practice, the bug is almost always in canonicalization: parameter ordering, encoding, host or path formatting, timestamp formatting, or use of the wrong secret key.

How the Signature Is Built

MWS signing is based on a string to sign that includes:

1. the HTTP method
2. the lowercase host
3. the request URI
4. the canonical query string

That string is then HMAC-signed, usually with SHA-256, and base64-encoded.

If any part of the string differs between your code and Amazon's interpretation, the signatures will not match.

The Most Common Causes

The usual mistakes are predictable:

• parameters are not sorted lexicographically
• a parameter value is encoded incorrectly
• spaces become + instead of %20
• the request path is wrong
• the host does not match the endpoint actually called
• the timestamp is malformed
• the wrong secret key is used

Even one character difference is enough to fail authentication.

Build the Canonical Query Carefully

The query string must be sorted by parameter name and encoded exactly once. Do not sign raw values one way and send them encoded another way.

Here is a small Python example showing the general idea:

1from urllib.parse import quote
2
3
4params = {
5    "Action": "ListOrders",
6    "AWSAccessKeyId": "AKIAEXAMPLE",
7    "SellerId": "A1EXAMPLE",
8    "SignatureMethod": "HmacSHA256",
9    "SignatureVersion": "2",
10    "Timestamp": "2025-09-23T03:30:00Z",
11    "Version": "2013-09-01",
12}
13
14parts = []
15for key in sorted(params):
16    encoded_key = quote(key, safe="-_.~")
17    encoded_value = quote(params[key], safe="-_.~")
18    parts.append(f"{encoded_key}={encoded_value}")
19
20canonical_query = "&".join(parts)
21print(canonical_query)

The safe="-_.~" part matters because MWS expects RFC 3986 style encoding.

Check the String to Sign

Once the canonical query is correct, the string to sign should look like this pattern:

1POST
2mws.amazonservices.com
3/
4Action=ListOrders&AWSAccessKeyId=...

Many debugging sessions end quickly once you print the exact string to sign and compare it with a known-good example.

Timestamp and Clock Problems

Your timestamp must use the required ISO 8601 format, and your system clock should be close to real time. If the timestamp is malformed or the clock is badly skewed, authentication can fail even if the HMAC code itself is correct.

For old MWS integrations, this is especially easy to miss because the signing code may have been copied from legacy examples and never revisited.

Practical Debugging Strategy

When the error appears:

1. log the full canonical query string
2. log the exact string to sign
3. confirm parameter sort order
4. confirm percent-encoding rules
5. confirm the host and URI match the request endpoint
6. verify the secret key and timestamp

If you are using a language helper library, inspect what it actually sends over the wire instead of assuming the library is correct.

It also helps to test with the smallest possible request. Removing optional parameters makes the canonical string shorter, which makes ordering and encoding bugs much easier to spot by eye.

Common Pitfalls

• Encoding parameters twice.
• Using + for spaces instead of %20.
• Signing one host name while calling another endpoint.
• Sorting parameters incorrectly or forgetting to include one.
• Using expired or mismatched credentials.

Summary

• The error means your string-to-sign process does not match Amazon MWS's reconstruction.
• Focus first on canonical query generation, encoding, host, path, and timestamp.
• Print the exact canonical query and string to sign during debugging.
• Small encoding differences cause total signature failure.
• Fix the canonicalization bug and the signature mismatch usually disappears immediately.