WeatherKit REST API down?

Question

Created Jun ’24

Replies 7

Boosts 3

Participants 6

I'm just getting 400 error responses to my requests sent to the WeatherKit REST API... haven't changed anything in my code for months.

Here is the verbose output from curl:

# curl -v "https://weatherkit.apple.com/api/v1/weather/en/51.5203/-0.1775?dataSets=forecastHourly%2CforecastNextHour&hourlyEnd=2024-07-04T09%3A03%3A36.962Z&hourlyStart=2024-06-24T09%3A03%3A36.962Z" -H "Authorization: Bearer [REDACTED]"
*   Trying 23.73.4.202:443...
* Connected to weatherkit.apple.com (23.73.4.202) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=California; O=Apple Inc.; CN=weather-data.apple.com
*  start date: May  8 16:30:14 2024 GMT
*  expire date: Nov  4 16:40:14 2024 GMT
*  subjectAltName: host "weatherkit.apple.com" matched cert's "weatherkit.apple.com"
*  issuer: C=US; O=Apple Inc.; CN=Apple Public Server ECC CA 1 - G1
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /api/v1/weather/en/51.5203/-0.1775?dataSets=forecastHourly%2CforecastNextHour&hourlyEnd=2024-07-04T09%3A03%3A36.962Z&hourlyStart=2024-06-24T09%3A03%3A36.962Z HTTP/1.1
> Host: weatherkit.apple.com
> User-Agent: curl/7.81.0
> Accept: */*
> Authorization: Bearer [REDACTED]
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Server: Apple
< Content-Length: 0
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=31536000; includeSubdomains
< X-XSS-Protection: 1; mode=block
< Access-Control-Allow-Origin: *
< X-Content-Type-Options: nosniff
< Content-Security-Policy: default-src 'self';
< X-REQUEST-ID: ed7d038c-ef82-61d8-a2cb-4522ff7d32ca
< X-Apple-Origin: fdcbff05-73b4-3a53-948b-343caa55a40e
< Date: Mon, 24 Jun 2024 09:18:00 GMT
< X-Cache: TCP_MISS from a23-73-3-202.deploy.akamaitechnologies.com (AkamaiGHost/11.5.2-56655770) (-)
< Connection: keep-alive
< 
* Connection #0 to host weatherkit.apple.com left intact

Boost

Answer 1

stoic_matsumoto OP

Jun ’24

We have started experiencing a similar issue since start of last week -- HTTP 400 out of nothing.

Then we tried without argument 'hourlyEnd' and it worked, but result contains only next 24 hours.

Then we tried adding back argument 'hourlyEnd' that is about 10 days ahead of current time (~240 hours) and errors came back again.

Then we tried adjusting argument 'hourlyEnd' by moving it a bit earlier, between 230 and 235 hours ahead of current time, and for some geographical locations closer to GMT it worked, but for other locations towards East it needed a lower value.

Our guess is that if requested argument 'hourlyEnd' happens to be greater than the what the hourly forecast can return furthermost in the future, then the request is rejected with HTTP 400.

It would be better if the API only returned what is available instead of totally failing.

2

Answer 2

drmrbrewer OP

Jun ’24

Thanks for the observations @stoic_matsumoto. I'll go down that route and see if I find the same. If true, and we need to second guess how many hours of data might be available in any given time zone to avoid a 400 error (and possibly taking into account other factors beyond our control) then this is indeed truly horrible :-0 Ideally we should just be able to ask for a certain number of hours from a given start time (defaulting to "now") and we should receive whatever is available up to the requested number of hours.

0

Answer 3

drmrbrewer OP

Jun ’24

@stoic_matsumoto at present I calculate hourlyEnd to be 10 days after hourlyStart...

Firstly, it's really not very elegant to have to do calculate either of these two dates in an absolute sense, and it should instead be possible to specify these relatively i.e. "10 days of data starting from now".

Anyhow, I reduced the calculation from 10 days to 9 days (just to be sure), and indeed there now appear to be no 400 error responses.

Hopefully a dev at Apple is reading these forums and can understand that this situation isn't ideal in any respect. I think these error responses must have only started around 5 or so days ago... so something must have changed in the backend around then. Would be nice to have the full 10 days of data back.

1

Answer 4

sunsetlover OP

Jun ’24

I've been having these same errors too. Initially, I reduced my app to only use 9 days of future data since the 10 day forecast would randomly throw 400s, but randomly today, it didn't even give me that much!

Now I've had to reduce it to use 8 days worth.

This really needs to be fixed.

Also, 100% agree that specifying the number of days in the future instead of me calculating the hourlyEnd would be much more intuitive.

1

Answer 5

ecuador OP

Jun ’24

This is still happening. Very bad API behaviour.

1

Answer 6

Drnb OP

Jun ’24

Is there a way to be notified when they change such things?

1

Answer 7

ejrice OP

Jul ’24

Any update on this? This is still an active issue.

1