Apple Music API lookup broken

[shakgrig]

I noticed today that when Harmony tries to look up Apple Music links or any UPC, fails to fetch the resource every time. I'm pretty sure this was working fine yesterday, so I assume something changed on Apple's end.

https://harmony.pulsewidth.org.uk/release?url=https%3A%2F%2Fmusic.apple.com%2Fus%2Falbum%2F1705930398&gtin=&region=GB%2CUS%2CDE&itunes=

https://harmony.pulsewidth.org.uk/release?url=&gtin=3616841551815&region=gb%2C+us%2C+de&itunes=

[atj]

It appears that Apple is intermittently returning 403 responses at the moment. It's difficult to tell if this is specific to the source IP of the server at harmony.pulsewidth.org.uk. I've seen weird behaviour like this in the past with a-tisket, but it's never seemed like it was due to rate limiting:

$ curl 'https://itunes.apple.com/lookup?entity=song&limit=200&upc=748777235132&country=gb' -v
[...]
< HTTP/2 403
< x-responding-instance: MZStoreServices:4132007:::
< apple-timing-app: 2 ms
< access-control-allow-origin: *
< x-apple-lokamai-no-cache: true
< content-length: 0
< expires: Thu, 15 Aug 2024 17:55:43 GMT
< cache-control: max-age=0, no-cache, no-store
< pragma: no-cache
< date: Thu, 15 Aug 2024 17:55:43 GMT
< x-cache: TCP_MISS from a2-21-35-94.deploy.akamaitechnologies.com (AkamaiGHost/11.6.1-8b2dfe3939b99771c02ec6eca94739cd) (-)
< x-true-cache-key: /L/itunes.apple.com/lookup vcd=2897 ci2=country=gb&entity=song&limit=200&upc=748777235132///
< x-cache-remote: TCP_MISS from a23-204-110-26.deploy.akamaitechnologies.com (AkamaiGHost/11.6.1-8b2dfe3939b99771c02ec6eca94739cd) (-)
< x-apple-partner: origin.0

$ curl 'https://itunes.apple.com/lookup?entity=song&limit=200&upc=748777235132&country=gb' -v
< HTTP/2 200
< x-apple-jingle-correlation-key: 42PJGXAQ5W7NWSCEHFJVZ366HU
< x-apple-request-uuid: e69e935c-10ed-bedb-4844-39535cefde3d
< x-apple-translated-wo-url: /WebObjects/MZStoreServices.woa/ws/wsLookup?entity=song&limit=200&upc=748777235132&country=gb&urlDesc=
< apple-tk: false
< x-b3-spanid: 20f876930ec78c3c
< content-type: text/javascript; charset=utf-8
< b3: e69e935c10edbedb484439535cefde3d-20f876930ec78c3c
< x-content-type-options: nosniff
< x-b3-traceid: e69e935c10edbedb484439535cefde3d
< x-webobjects-loadaverage: 0
< x-responding-instance: MZStoreServices:4062004:::
< apple-seq: 0
< content-disposition: attachment; filename=1.txt
< apple-originating-system: MZStoreServices
< strict-transport-security: max-age=31536000
< x-apple-orig-url: https://mzstoreservices-int.itunes.apple.com/lookup?entity=song&limit=200&upc=748777235132&country=gb
< x-apple-application-site: MR22
< apple-timing-app: 364 ms
< x-apple-application-instance: 4062004
< cache-control: max-age=86266
< date: Thu, 15 Aug 2024 17:57:48 GMT
< content-length: 5528
< x-cache: TCP_HIT from a2-21-35-94.deploy.akamaitechnologies.com (AkamaiGHost/11.6.1-8b2dfe3939b99771c02ec6eca94739cd) (-)
< x-true-cache-key: /L/itunes.apple.com/lookup vcd=2897 ci2=country=gb&entity=song&limit=200&upc=748777235132///
< x-apple-partner: origin.0
<
{
 "resultCount":4,
[...]
}

My advice at this point would be to try running the query again after a few seconds and it may well work.

[shakgrig]

Nope, still nothing. A-tisket is also being weird and seems to be only returning Apple data sometimes, and only if looked up with the UPC along with a Spotify link, adding the Apple link directly breaks it, even it it already had previously pulled the data. Maybe this will resolve itself after a day.

[shakgrig]

Both Harmony and a-tisket seem to be working again, so I guess Apple just temporarily broke something.