...It seems I resolved one issue (with how I was sending the request in Postman) and have upgraded my error to now be "{"reason": "NOT_ENABLED"}" which is a 401 ...The documentation says 401s will result from an invalidly-formed token. I am wondering if there is a Public key to utilize at jwt.io in order to sign one's private key correctly (since the default public key at the site when left in results in an invalid signature).

Same here. However, I am wondering if it's a false error - and the true culprit is something else (e.g., maybe an unsigned or otherwise incorrect token - per my comment above about the public key).

@rubynerd - is there any possible chance you might be able to document how to set this up in Postman (so it is generally agnostic of other code)? I am getting a 403 and have yet to determine the culprit. Thanks for any possible consideration, and for everything you already did here.

@Compelling - I have included one dot in between, two dots, and three dots ... I still get back a 403 in every regard, unfortunately.

We tried https://weatherkit.apple.com/api/v1/availability/36.328050/-82.392050 well (in case location being queried mattered). Also: uncertain whether we need to pass in our value for "Services" somehow else (this alongside Name and, of course, our Key were the three properties in the downloaded file after initial configuration in the Apple Developer portal).

We have ensured this is enabled in both "capabilities" and "app services" yet I am nonetheless getting a 403 as follows: {"timestamp":"2023-03-21T19:18:34Z","status":403,"error":"Forbidden","path":"/api/v1/weather/en/51.677612/-2.937941"} ... My hunch is maybe rather than understanding the Service Id to be what's labeled "Bundle Id" (under Certificates, Identifiers & Profiles) - we should instead be using something else (e.g., Description, with no space or "Name" in the downloaded file)?