FYI: code 106 "Illegal sign" can mean "the key's project is not approved yet" - how to tell it apart + two policy questions (long-term personal use / token validity)

Developer Hub
1

Hi everyone,

Posting a finding that cost me a lot of time, in case it helps others - plus two questions for
the Aqara Developer team. For context: my project has been “pending review” for 26 days, and the
only reply I got (Sept 21) was a canned “account authorized” note that changed nothing - it is
still pending and its keys still return code 106.

THE FINDING: code 106 “Illegal sign” is not only about the signature

I had a project sitting in “pending review”, and every signed request returned:

HTTP 200 / code 106 / messageDetail "Illegal sign"

I checked the obvious things, all of which passed:

  • Signature reproduced byte-for-byte against the sample in the API guide
    (expected Sign bfd8dd0e7c108353e6740d81e05982d8 → matched exactly).
  • Both KeyId notations tried (with and without the “K.” prefix).
  • The same credentials sent to all six regional gateways (open-cn / open-usa / open-ger /
    open-kr / open-ru / open-sg .aqara.com) - all six returned byte-identical responses.
  • A deliberately invented AppId returns exactly the same code 106.

Then I ran a controlled comparison on the same endpoint at the same moment, changing only which
project’s credentials were used:

Project A (pending review) -> code 106 "Illegal sign"
Project B (approved)       -> code 108 "Parameter AccessToken illegal"

code 108 means the server accepted the credential set and was only waiting for an access token -
so the signature was correct all along. In my case, “Illegal sign” effectively meant “this key
belongs to a project that has not been approved yet”.

Suggestion for the platform team: since a made-up AppId returns the same code, the message has no
diagnostic value and sends developers looking for a bug in their own signing code. A separate code
for “project not approved” would help a lot.

After that, the authorization flow (getAuthCode → getToken) worked and I could list my devices.

TWO QUESTIONS

  1. Long-term use of an approved project whose purpose line says “调试使用” (debugging).
    My use is personal and non-commercial: a self-hosted Home Assistant in my own home reads and
    controls my own devices, tens of thousands of calls per month, inside the free quota, nothing
    published and no third-party service. Is it acceptable to keep using that approved project
    long-term for this, or does Aqara expect the credentials to come from a project whose declared
    purpose matches the actual use? If the latter, what wording would you suggest for the purpose
    field, and does editing it affect the review? I would rather ask now than find out later.

  2. Token validity. The token response returns expiresIn = 3600 (1 hour). The June 2026 platform
    notice says the maximum authorization validity is now 30d, and the SDK example uses
    access_token_validity = ‘7d’. Can an individual project request 7d / 30d, and is periodic
    renewal via config.auth.refreshToken the recommended pattern for a long-running local
    integration? (I tested it and it returns a new token pair successfully - just confirming it is
    the sanctioned approach.)

If anyone else has hit a project stuck in review and can say what actually unblocked it, I would
be glad to hear it.

image
image2303×299 40.2 KB

Thanks,
Stephen Guo

1 Like
2

Hello and a very warm welcome to the forum.

For non-paying corporate/individual developers, only the default project is supported. As I mentioned in another post: Project approval

It’s the same for me. The access token is only valid for one hour. With the refresh token, which I think is valid for 30 days by default, you can obtain a new access token without having to go through the authentication process again.

I’m not sure right now, but I think the example in the documentation was wrong. If I remember correctly, you have to do it exactly as described, and not the way the example suggests.

1 Like