Instagram TV oneboxing

Sorry if this has been discussed before, but is support for oneboxing IGTV links on the roadmap?

When I try to use a IGTV link, which is something like, the response is similar to the described in this topic:

cURL’ing this link there are og:image, og:description, og:video, etc.

After a quick look, the URL is not supported on the Instagram oneboxing engine:



Should this work @jamie.wilson?


An IGTV link would, as it stands right now, be routed via the Generic oneboxer, which would (probably) work for the first handful of requests from any given site. After a small number of requests, IG will (probably) redirect those requests to a login screen which is what @renato is seeing.

As @renato points out, the IG onebox engine isn’t setup to handle IGTV style links. I’ve just created a PR to do this:

This means the IG onebox engine will fetch the IG TV URL via the official IG oEmbed endpoint and, assuming you’ve configured an access token, the onebox URL request shouldn’t be redirected to a login screen.

(The onebox PR request will require a onebox version bump, and then an update of the Gemfile in Discourse core.)


Thanks, you guys rock!

Just a thought: could we leverage the returned og:video (which has secure_url, type, width and height) to show a video player, like the generic engine?

We’re using the Instagram oEmbed API endpoint, which doesn’t return the media type, or URL to the video file, or anything else useful that would allow us to construct a onebox with an embedded player.

While accessing the page directly does contain this metadata, doing so more than a handful of times in a non-authenticated manner seems to trigger a state on the remote end where they will start requiring authentication. This is why the link in your first post is pointing to a login page.

As far as oneboxing goes, it seems as though we’re fairly limited in what we can do with IGTV links at the moment.


Using the oEmbed API there’s an html attribute returned, I see there’s an old discussion proposing using this returned html but it ends up leaning towards the current solution.

I understand the current approach is cleaner and safer, so it makes sense to keep it on core.

Not something I really need currently, but if I happen to need it, a custom plugin for using this “official” Instagram embedding – enforcing a fixed height and fallbacking to the core solution – would be feasible? Can I have another Onebox engine with the same matches_regexp or should I try monkey patching Onebox::Engine::InstagramOnebox?


priority can help control which engines match specific URLs.

Also note the approach RedditMediaOnebox takes. It will try to return custom HTML, but will fallback to a generic onebox if it doesn’t know how to process that specific type of result.