DynamoDB IncompleteSignatureException

TL;DR — The request's AWS Signature Version 4 signature was incomplete or didn't conform to AWS standards, so DynamoDB rejected it before authenticating. If you use an AWS SDK the signing is automatic — this almost always means a hand-built request or a proxy/gateway that mangled the Authorization header after signing. Let the SDK sign, and make sure nothing rewrites the request in transit.

What it means

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS signs every request with SigV4. This exception means the signature was present but malformed or missing required components — a bad Authorization header, a missing signed header, or a canonical-request mismatch. It's an HTTP 400, client-side, and not retryable as-is: the signature has to be corrected.

Why it happens

Hand-rolled signing — you're building the SigV4 signature yourself (not through an SDK) and the canonical request, signed-headers list, or Authorization header is wrong.
A malformed Authorization header — the documented triggers are an empty header, a missing Credential or Signature parameter, a header that doesn't start with the algorithm name (AWS4-HMAC-SHA256), or a key=value pair without an equal sign.
A proxy or API gateway rewrote the request — mutating the Authorization header (or other signed parts) after the SDK signed it makes the header AWS receives differ from the one you sent.
Manually edited headers — adding/removing headers after signing, or reordering the query string, breaks the canonical request.

How to fix it

Use an official AWS SDK and let it sign the request. The SDKs implement SigV4 correctly for you — the fix for almost every occurrence is to stop hand-signing.
Don't mutate the request after signing — if a proxy/gateway sits in front, make sure it doesn't add, drop, or reorder headers or change the body/path. Sign at the edge that actually sends the request.
Check whether the Authorization header changed in transit — AWS's documented diagnostic: compute a SHA-256 hash of the header you sent, Base64-encode it, and compare it with the hash some IncompleteSignatureException messages include. If they differ, something between your client and AWS modified the header.
If you must sign manually, follow the AWS SigV4 signing process exactly — the canonical request, the string-to-sign, the signing key derivation, and the Authorization header (algorithm, Credential=, SignedHeaders=, Signature=) must all match. Verify against a known-good SDK request.

A wrong or truncated secret key is a different failure: it produces a complete signature that doesn't match, surfacing as "signature we calculated does not match" rather than this error. Likewise, a skewed machine clock surfaces as Signature expired, not an incomplete signature.

DynoTable + Local

DynoTable uses the AWS SDK signing path — no hand-built SigV4 — so this error class does not appear in normal use. If your app hits it while DynoTable works, compare profiles: Settings → Profiles → Test Connection with the same keys your app loads.

For Local, dummy credentials on a profile with endpoint http://localhost:8000 bypasses signing entirely. See Connect to AWS and Install. After credentials resolve, run a smoke-test query in the Query Builder.

Sources

Error handling with DynamoDB — IncompleteSignatureException (verified 2026-07-13)
Troubleshoot Signature Version 4 signing (verified 2026-07-13)

FAQ

What causes an IncompleteSignatureException? The AWS SigV4 signature on the request was malformed or missing required parts — an empty or malformed Authorization header, a missing Credential or Signature parameter, or a key=value pair without an equal sign. With an AWS SDK signing is automatic, so it usually means a hand-built signature or a proxy that altered the request after signing.

How is this different from UnrecognizedClientException? IncompleteSignatureException means the signature itself was malformed. UnrecognizedClientException ("security token is invalid") means the signature was well-formed but the credentials behind it weren't accepted.

Reproduce it

Send an Authorization header that is present but not parseable as SigV4:

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

Real output:

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400

The trailing Base64 string is a hash of your own header, so it differs on every request — do not match on it. What the message is telling you is structural: AWS could read the algorithm but not the Credential=/SignedHeaders=/Signature= pairs after it. That points at how the header was assembled, which is why this almost always comes from hand-rolled signing rather than from an SDK.

The request signature we calculated does not match — a complete but wrong signature (bad secret key or canonicalization).
The security token included in the request is invalid — well-formed signature, bad credentials.
The security token included in the request is expired — temporary credentials timed out.
Missing region in config

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Reproduced 2026-07-26 against the live DynamoDB service in us-east-1 — the output above is verbatim.