Apple Weather — how to connect

The plugin ships one node type, AppleWeather/Weather: a node whose page is a weather dashboard — one card per place with current conditions and the daily forecast. The WeatherKit developer key belongs to the instance: an administrator sets it once in Administration › Integrations, and nobody else is asked for a key. You only pin your places, in the Apple Weather tab of your own settings (/{you}/Settings/AppleWeather); they are stored in your own space and nobody else can read them.

A key you stored yourself before this change keeps working until the instance key is set (your page says so), stays private to you, and is never copied anywhere.

1. Create the WeatherKit credentials (administrators; Apple Developer Program required)

WeatherKit needs two things from developer.apple.com/account, and people routinely miss the second:

1. A key — Certificates, Identifiers & Profiles ▸ Keys ▸ +, name it and enable WeatherKit. Download the .p8 (Apple offers this exactly once) and note the 10-character Key ID.
2. A Services ID configured for WeatherKit — Certificates, Identifiers & Profiles ▸ Identifiers ▸ +: first register an App ID (e.g. com.yourname.weather) with the WeatherKit capability ticked under both Capabilities and App Services, then register a Services ID (e.g. com.yourname.weather-web) grouped with that App ID. The Services ID identifier is your serviceId — the REST API's token names the Services ID, and WeatherKit refuses a key alone.

Your 10-character Team ID is under Membership details. A newly enabled capability can take a few minutes to propagate on Apple's side.

2. Set the instance key, then pin your places

Administrators open Administration › Integrations and set the four values once. Each is write-only: it is encrypted, filed as a secret write for the control plane, and shown afterwards only as a mask.

Everyone pins places, one per line as Name; latitude; longitude (for example Zurich; 47.3769; 8.5417), and may set the forecast language (en, de, …).

Each location becomes a card: the current conditions line (temperature, feels-like, humidity, wind, UV) and the daily forecast as a data grid — day, pictogram, condition, min, max, rain. The card is built from the platform's controls, so its labels and column headers follow your language (English or German) while the numbers stay as WeatherKit reports them. Refresh re-reads WeatherKit; the page never polls on its own.

Time — two different rules, both deliberate

• Forecast days are calendar facts. A forecast for 2026-08-21 is for 2026-08-21 — the day boundaries are computed in your time zone (the request asks WeatherKit for them), and the named date is never shifted afterwards.
• Instants convert. The "as of" stamp under the current conditions is a moment in time and renders in your own time zone.

Attribution — a license requirement

Apple's WeatherKit terms require visible attribution wherever the data appears. Every rendered page — the setup and empty states included — therefore carries the Apple Weather footer linking Apple's data-source page. Keep it — removing it puts your WeatherKit access out of compliance. (The label is the plain words "Apple Weather": Apple's mark is a private-use glyph that renders as an empty box outside Apple's own platforms.)

Security, by design

• The .p8 key signs server-side. Only short-lived (1-hour) service tokens ever leave the mesh; the key itself never travels.
• Secrets render only as masks — ···· plus the last four characters. The instance key lives in the vault, never in node content; a legacy key you stored yourself stays in your own space.
• Revocation is instant: delete the key in the developer portal.

What the mesh calls

weatherkit.apple.com — /api/v1/weather/{lang}/{lat}/{lon} (current conditions + daily forecast), one GET per pinned place per refresh, through the mesh's bounded HTTP pool; a stalled call degrades to a diagnosis on the page, never a hang. Your developer membership includes 500,000 calls per month — a dashboard refreshed by hand does not approach it.