Clone wiki

cloudengine / oEmbed

Embedding/ oEmbed

Authors on a CloudEngine-powered site, for instance Cloudworks, have the opportunity to embed content from third party sites such as YouTube, Flickr and Slideshare in their Clouds. To allow embedding, CloudEngine uses a service-based standard called oEmbed. CloudEngine acts as consumer or client while YouTube, Flickr, Slide share and others act as providers.

This document explains the specific requirements of CloudEngine (and Cloudworks), and builds on the oEmbed standard specification. Note that the requirements of CloudEngine are not very different from that of other consumers.

Guidelines for service providers

  1. Read the specification at
  2. URLs should be permanent and unchanging, eg. ,
  3. A unique URL is required for (to represent) each asset that is to be embedded, eg. each track in a podcast album, each photograph.
  4. CloudEngine uses the jquery-oembed Javascript plugin. This means that CloudEngine requires a response in JSON format (Javascript Object Notation) (see the array of supported providers in the Javascript code). Of course, you are encouraged to provide an XML response as well.
  5. It also means that the service needs to provide a JSON-P (JSON with Padding) response. That is, the caller can specify a callback function, and the service wraps it's response in this function call. The callback parameter can be named anything, as long as it is documented.
  6. As noted in the specification, for security, the response should not contain Javascript. For popup windows see the up-popup proposal. A workaround, which is not ideal in terms of complexity or accessibility is to respond with an <iframe>.
  7. The response should be designed with accessibility, usability and standards in mind. This includes, but is not limited to, adding ALT attributes to all images in the response (which may be empty for decorative images), and adding text to all links (which may be ALT text). You should refer to the Web Content Accessibility Guidelines 2.0.

With regard to the last two points, you should bear in mind that the response is embedded directly in the consumer's page, so the provider has a responsibility to not compromise an otherwise secure and accessible page.

Also note that points 2, 5 and 7 would apply however you wish to deliver embed code - they are not restricted to oEmbed.


To afford the maximum interoperability, we suggest that as a minimum oEmbed services should be tested with: