Hey Everyone, I am looking for some help as I am completely lost in what to do, maybe I am missing something simple, but, our server-side WeatherKit REST integration has returned 401 on every request for several weeks, and the evidence points to service enablement on Apple's side rather than our configuration.
Details:
The 401 response body is {"reason": "NOT_ENABLED"}, per the documentation this indicates the WeatherKit service is not enabled for the App ID, not a malformed token. Deliberately corrupting the JWT produces a different rejection, which we can reproduce at will, so token validation is clearly passing.
The JWT is structurally correct: header {alg, kid, id: "TEAM.BUNDLE"}, payload {iss: TEAM, sub: BUNDLE}. The same Team ID and signing flow produce a working MapKit JS token in production today.
In Certificates, Identifiers & Profiles, the WeatherKit capability is checked for the App ID under both App Services and Capabilities, and has been for weeks. We have since minted a brand-new key (new .p8, re-encoded and verified) and the result is unchanged.
Bundle ID: run.tayro.app. The failure is identical from our production servers and from curl.
Developer Support declined to escalate twice, saying this is outside their scope so I'm posting here for help :) . Has anyone seen NOT_ENABLED persist despite the portal showing the capability enabled? And long shot but... maybe someone from the WeatherKit team can check the service enablement state for this App ID? or point me at the right channel to request that?
SOLVED and posting the resolution for the next person who hits this.
Symptom: WeatherKit REST API returned 401 with NOT_ENABLED on every request, even though the WeatherKit capability was checked on the App ID, the entitlement was in the app, and the JWT was signed correctly with a valid key.
Root cause: the App ID has WeatherKit in TWO places in the developer portal, and they are independent checkboxes. Certificates, Identifiers & Profiles -> Identifiers -> your App ID has both a "Capabilities" tab AND an "App Services" tab. WeatherKit appears on both. Ours was checked under Capabilities but NOT under App Services. The service-side flag is what the REST API checks, so everything client-side looked correct while the API kept answering NOT_ENABLED.
Fix: Identifiers -> select the App ID -> App Services tab -> check WeatherKit -> Save (accept the provisioning profile invalidation; installed builds keep working and the next build regenerates profiles). Our REST calls started returning live weather within minutes, same JWT, no code changes.
Credit where due: an Apple DTS engineer describes this exact one-of-two trap in thread 835229, which is how we finally found it. If you are staring at NOT_ENABLED with correct entitlements and a correct JWT, check the App Services tab before anything else.
