This isn't very well documented, but Soundcloud's HTML5 widget works as well with normal URLs - like the use in their flash widget - as it does with their preferred API URLs.

One of the suggested routes to get the API URL is to use their /resolve endpoint which you give a regular URL such as https://soundcloud.com/jackconte and it responds with a 401 redirect to  https://api.soundcloud.com/users/19328797. This is nice, but the reason their flash widget integrated well into hubski was a user just had to give the regular URL and we could generate the code for the widget from it. To use the HTML5 widget - and get the benefits of being able to embed audio in mobile browsers - we would have to set up an extra API call with Soundcloud to get a client id in order to use the endpoint at all.

Another way is to use their /oembed endpoint. You can send the URL and get back a JSON payload which includes the full html for the widget. This simplifies things greatly and you can make a client side request like this

<div id=\"sc\"></div>
<script>
var URL = \"https://soundcloud.com/jackconte\"

$.getJSON(\"http://soundcloud.com/oembed?format=json&url=\" + URL, function( data ) {
  $('#sc').append(data.html);
});
</script>

to render the widget. This is especially useful if they ever change the widget HTML format and you don't need to register a client id.

Ideally, I'd like to do a simple transform on the URL and spit out the HTML for the widget à la youtube. I was trying to set this up and I couldn't find any easier way of doing this so I thought I'd see what would happen if I shoved the URL in like so:

<iframe id='sc-widget' width='100%'' height='166' scrolling='no' frameborder='no' src='https://w.soundcloud.com/player/?url='https://soundcloud.com/jackconte&show_artwork=true'></iframe>

To my surprise it just worked, as you can see here

I'm not that surprised that they haven't documented this that well; there are a lot of benefits of forcing developers to register and go through your API. For now it serves its purpose, but I'll likely change to a more robust client side version using oEmbed when Hubski's frontend is refactored.