search

soundcloud / api

A public repo for our Developer Community to engage about bugs and feature requests on our Public API
147 stars 23 forks source link

Oembed Gone? 404 status - looks like it's back (for good?) #247

Closed tristan-misinc closed 1 year ago

tristan-misinc commented 1 year ago

Client reported issue with embeds not working on their site today. Was working until recently. https://developers.soundcloud.com/docs/oembed - states oembed endpoint is https://soundcloud.com/oembed The endpoint returns 404 now, with or without query parameters. No updates to documentation or announcements of retirement.

Was this silently retired or is this a problem on soundcloud's end?

Very urgent - I'm sure my client isn't the only user for the oembed endpoint. We need to fix this ASAP, so if this endpoint is not coming back, we need to find another solution.

Thanks

stevereinvented commented 1 year ago

Similar issue here today but 403 instead. The oEmbed is working from a UK IP address, but not the one where the wordpress.com blog is hosted. Headers:

HTTP/1.1 403 Forbidden
Server: CloudFront
Date: Mon, 03 Jul 2023 11:26:51 GMT
Content-Type: text/html
Content-Length: 919
Connection: keep-alive
X-Cache: Error from cloudfront
Via: 1.1 1ad4f21710c30c86f0c2c6495ab30228.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: IAH50-P2
X-Amz-Cf-Id: 2mjmu9FherXgLrKufaX5pR9mnQFuh1aL5rJXOClGAc4tx51yr03Jug==

Body:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: Yg69Hhfgqhd9dAlRnEU1plt_1_oQh22gfZuXjXV4Iw2qDcn6vHLUnQ==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
GabrielMartinsCarossi commented 1 year ago

Same issue here. I'm getting 403 in production, but it works fine on my local environment.

SoundCloud published this vague update: https://developers.soundcloud.com/blog/an-empty-blogpost

mediaexplorer74 commented 1 year ago

SoundCloud published this vague update: https://developers.soundcloud.com/blog/an-empty-blogpost

Wow, fresh post by Jordan Pettinato, after 2 years of total silence :) Thank you, it's some hope for best SoundCloud API future ;))

tristan-misinc commented 1 year ago

Appears I'm receiving the 403 as well when accessing via cURL on my production server - the 404 is when pulling the endpoint up from a browser. No response body at all with the 403. Should have verified it was returning the same as what I had on a browser.

If the oEmbed endpoint is being moved non-public or something, that'd be totally fine - we just need the ability to ask for credentials for this endpoint. We have a client relying on this endpoint to serve their content to their paying subscribers. It's not a good look at all for soundcloud or us as developers.

The lack of response from support on this is chilling :(

tristan-misinc commented 1 year ago

We're back up today - still receiving a 404 via browser for the endpoint without parameters, but with parameters and via cURL requests from our production server, we're getting 200 with good response data. A big thank you to whoever behind the scenes has opened the endpoint up :)

Any official or unofficial updates from the soundcloud API team would be greatly appreciated, either here or through the support tickets filed. Our client is overjoyed to see their streaming audio files working again, but I can't tell them why nor assure them things will continue working.

tristan-misinc commented 1 year ago

The oEmbed endpoint seems to be working fine still after a little more than a week, so I'm going to close this issue - just wish we had some sort of verification that this will continue working going forward.