Nearly six years ago, we watched Instagram embeds break across all WordPress sites overnight.
In October 2020, Meta announced that its oEmbed endpoints would require an access token, and just like that, the “paste-a-URL-and-it-works” experience that WordPress users had enjoyed for years was gone. WordPress core ended up pulling Facebook and Instagram embed support entirely, because there was no sane way to ship token management to millions of site owners.
As of 15th June 2026, Meta has reversed that decision.
Their announcement is short and easy to miss, but it matters if you build or maintain WordPress sites. The Meta oEmbed APIs for Instagram, Facebook, and Threads can now be called without an access token, and App Review is no longer required. If you’ve developed anything that required Meta API access, you understand why that App Review point is so important – it can be a nightmare to get approval.
In this piece I’ll cover what actually changed, the history most coverage will skip, and, importantly, what this does not change. There’s already some confusion about whether this affects Instagram feed plugins, and I can confirm it doesn’t, and I’ll explain why.
What Changed on 15th June 2026?
The change applies to four endpoints:
- Threads oEmbed
- Instagram oEmbed
- Facebook oEmbed Post
- Facebook oEmbed Video.
Previously, calling any of these endpoints meant registering a Meta app, submitting an App Review request for the “Meta oEmbed Read” feature, and including an access token with every call.
Now you can hit the endpoints directly. No token, no review, and no developer account. The response is the same as before too, giving you the embed HTML, provider name, width, and content type. Meta also notes that no personal data is shared through these endpoints.
There are two caveats from the announcement worth flagging though. Firstly, tokenless access may come with lower rate limits than the token-based route, which still exists and works unchanged. The second is that the endpoints only work for public content.
If you weren’t running WordPress sites in 2020, it’s hard to appreciate how disruptive the original change was.
Embedding an Instagram post used to be a core WordPress feature. You pasted the URL on its own line and the embed appeared. When Meta locked oEmbed behind tokens, WordPress removed Facebook and Instagram as oEmbed providers from core, and every new embed attempt broke from that point on. Old embeds survived only because WordPress caches oEmbed responses in the database.
Jetpack scrambled to proxy requests through Automattic’s own token. Plugins like oEmbed Plus popped up asking regular site owners to generate Facebook App IDs and secrets.
But most people did neither. They probably just stopped embedding social posts or turned to dedicated plugins that handled the API connection for them.
That single decision reshaped a corner of the WordPress plugin ecosystem. A whole category of “fix your broken Instagram embeds” content and tooling exists because of it. Nearly six years of accumulated tutorials, support threads, and troubleshooting guides are now outdated because of one blog post.
The decision to reverse the 2020 change is quite telling. Meta’s stated reasoning in 2020 was privacy and security, but the new announcement simply says they’re “making it easier to embed public Meta content”. Read between the lines and this looks like Meta wanting its content circulating on the open web again, at a time when every platform is fighting for attention and AI answers are eating referral traffic.
Here’s the part that also got my attention as a publisher. Alongside the API change, Meta released Meta Embeds, an official open-source WordPress plugin, with the code public on GitHub.
It does exactly what you’d expect. Paste a Threads, Instagram, or Facebook URL into the editor and it renders a rich embed. No configuration, no tokens, no settings page. It works in both the block editor and the Classic Editor.
Meta shipping its own WordPress plugin is a notable move on its own. WordPress powers a huge share of the sites where this content gets embedded, and Meta clearly knows it.
There’s another detail buried in the plugin readme’s FAQs that hints at what’s next. The plugin checks whether your WordPress version already registers a Threads oEmbed provider and skips duplicate registration if so. That suggests native Meta embeds are finding their way back into WordPress core itself, so I’d expect Instagram and Facebook to follow. It’s something worth watching over the next few WordPress releases.
What This Doesn’t Do
Now for the confusion I mentioned earlier. At first glance, my initial question was whether this is something that would make Instagram feed plugins redundant. It doesn’t, and the reason is in what oEmbed actually is.
oEmbed is a single-post API. You give it the URL of one public post and it gives you back the embed code for that one post. That’s the whole contract.
There is no endpoint here for pulling an account’s latest posts, no hashtag feeds, no stories, and no way to build anything that updates itself. If you want your Instagram feed displayed on your site and kept current automatically, that still requires the Instagram API, with tokens, exactly as before.
So if you want to drop one Instagram post into a blog article, the free route now works again, and honestly, use it. If you want a live feed on your homepage that updates when you post, with layout control, filtering, and moderation, that’s still Instagram feed plugin territory.
One of those plugins is Spotlight Instagram Feeds, which, full disclosure, is developed by RebelCode, the company behind WP Mayor, and is highly-rated with 60,000+ active installations. Spotlight’s API connection and feed functionality are completely unaffected by this change.
There’s one more distinction worth understanding, and it applies to every oEmbed-based embed, including Meta’s own plugin. The embed HTML that comes back loads Meta’s JavaScript in your visitors’ browsers to render the post. Meta’s plugin readme is upfront that frontend rendering is subject to Meta’s privacy policy, so if you’re running sites for EU clients and thinking about GDPR, that’s a meaningful difference from solutions that render content natively without loading Meta’s scripts.
How This Change Affects You
If you maintain content or documentation that tells people Instagram embeds require tokens or a Meta app, it’s now wrong. We’re auditing WP Mayor’s own archive for exactly this.
If you build client sites, single-post Meta embeds are back on the menu without any developer setup. The official Meta Embeds plugin is the simplest route today, and core support may make even that unnecessary before long.
If you rely on an Instagram feed plugin, nothing changes. Check with your plugin’s developer if you’re unsure, but any feed solution built on the Instagram API is untouched by this, including the Spotlight Instagram Feeds plugin.
What Will WordPress Core Do Next?
Meta reversing a six-year-old decision that inconvenienced millions of site owners is a good outcome, whatever the motivation behind it. The open web works better when embedding public content is frictionless.
I’m more curious about what happens next.
Does WordPress core restore native Instagram and Facebook embeds? Does Meta keep investing in its official plugin, or does it quietly stagnate like so many official plugins do? Were you running WordPress sites when the 2020 change hit, and how did you handle it at the time?
I’d like to hear how much cleanup this creates, or saves, for you.
