The numerical weather service takes a bearer token. You exchange client credentials for one, then send it on every call. This is the scheme the service launched with, and it will move to the Insights api-key header alongside the host migration in the future.
Post your credentials as multipart/form-data. Your representative issues the client_id and client_secret by secure email.
Field
Value
client_id
Issued to you
client_secret
Issued to you
grant_type
client_credentials
scope
read:weather
The response carries access_token, token_type, scope and expires_in.
The token endpoint is not under the weather path
Forecast calls go to https://aviso-api.stratumfive.com/api/numericalweather/, and the token call goes to https://aviso-api.stratumfive.com/api/identity/connect/token. The identity service sits beside the weather service, not inside it.
expires_in comes back as 3600, so a token is good for one hour. No refresh token is issued: request a new one from the same endpoint when the old one runs out.
Cache until expiry
Requesting a token per call works and wastes a round trip on every forecast. Hold it for the hour, and a 401 narrows to the credentials.
Podium Metric I/O uses the same identity service and the same grant type. The scope differs, and so does the credential pair: your representative issues one pair per surface, and a token issued for one will not work on the other.