API authorization failed

[eutialia]

So after deploying it to my CF workers I keep getting this error from my unifi system:

 Temporary error in DDNS server response: DDNS server busy, try later

After some digging I found that it's because of how the script tries to authenticate itself by attaching the token in the header:

unifi-ddns/src/index.js

Line 63 in 7e12b8a

Authorization: `Bearer ${this.token}`,

This will lead to an API error from the CF:

{
  "success": false,
  "errors": [
    {
      "code": 6003,
      "message": "Invalid request headers",
      "error_chain": [
        {
          "code": 6111,
          "message": "Invalid format for Authorization header"
        }
      ]
    }
  ],
  "messages": [],
  "result": null
}

If I change the headers to include both X-Auth-Email and X-Auth-Key following the documentation, everything works as expected. I'm just not sure if this is due to some configuration error on my account, or CF has updated their API authorization logic.

[Dex1000]

Hi
I'm not the best with this kind of tinkering, what exactly did you modify within within index.js?

[MatthewA1]

I think your problem is with some configuration on your account. CloudFlare's API documentation makes the authentication methods for endpoints very confusing, but tokens are not only an allowed method, but are in fact the preferred method due to the ability to tightly restrict their scope.
Up until sometime in April or May 2023, Bearer Auth was still listed as a valid security option for the DNS endpoints; why it was removed from the documentation I have no idea. (See this snapshot from April 2023)
In the experimental new version of the API documentation, Bearer Auth still isn't listed as a method, but they changed the description for "API Email + API Key" authentication to make the usage of API keys vs tokens more clear:

The previous authorization scheme for interacting with the Cloudflare API, used in conjunction with a Global API key.
Example: X-Auth-Email: [email protected]
The previous authorization scheme for interacting with the Cloudflare API. When possible, use API tokens instead of Global API keys.
Example: X-Auth-Key: 144c9defac04969c7bfad8efaa8ea194

This community post by a CloudFlare employee confirms tokens are definitely the preferred method for API access, and in fact they are adding a account based tokens in addition to the user based tokens.

TL;DR

Tokens are still supported and in fact preferred, just the API docs don't make that clear so it's harder to find a definitive answer than I would have thought.

So were you originally trying to use an API token or an API key with the worker? Your Global API Key will definitely not work with this worker for the reasons you noted with the different headers that are used for the API key.
If you were trying to use an API token: What permission and resources did you assign to that token? Did you apply client IP address filters?