Does Instagram Have a Public API? What the Official Endpoints Actually Return

Instagram has official APIs, but they read accounts that have authorised your app. There is no documented endpoint that returns an arbitrary public profile's posts. The one outward-looking exception, business discovery, covers Instagram Business and Creator accounts only, and Meta switched off the Basic Display API on 4 December 2024.

That is the whole answer, and almost every page you will find on this subject buries it. What follows is the detail: which products exist today, exactly what each one reads, the two rate-limit systems that decide how much of it you can do, and what Instagram's own robots.txt says about the alternative. Every claim below is quoted from Meta's own documentation, read on 2026-09-12, with links at the end.

Does Instagram have a public API?

No, not in the sense people usually mean. Meta publishes two Instagram products, and both are authorisation-scoped: a person connects their Instagram professional account to your app, and your app then reads that account.

• Instagram API with Instagram Login "allows users of your app to access data in their Instagram Business and Instagram Creator accounts."
• Instagram API with Facebook Login for Business does the same "for Instagram Business and Instagram Creator accounts that are linked to a Facebook Page."

Two things follow that catch people out. First, personal accounts are not the subject of either product. Every documented capability is written against a Business or Creator account. Second, the older names are gone. Meta's Instagram Platform landing page no longer mentions "Instagram Graph API" or "Instagram Basic Display API" as products. The Graph API name survives only inside deep reference URLs, which is why half the tutorials you find describe a product that no longer has a front door.

What happened to the Instagram Basic Display API?

It was shut off. Meta's own changelog, dated 4 December 2024:

"The Instagram Basic Display API has been deprecated. All requests to the Instagram Basic Display API will return an error message."

Basic Display was the lightweight path: a person logged in with Instagram, and your app read their own media and profile. It required no Facebook Page and no business verification, which made it the backbone of a generation of consumer apps. TechCrunch reported at the time that the shutdown locked those apps out.

The replacement is Instagram API with Instagram Login, and the difference that matters is the account type: Basic Display worked with personal accounts, and its replacement does not.

Why the undocumented JSON endpoints stopped working too

For years, appending ?__a=1 to an Instagram profile URL returned that profile as JSON, and a window._sharedData blob sat in the page source. Both are gone for logged-out callers.

Be careful how you read that. Neither was ever documented by Meta, so no deprecation notice exists and nobody can point you at a dated announcement. What can be dated is when it was observed dead: a January 2024 issue on a widely used PHP library reports the endpoint returning "Sorry, this page isn't available."

The general lesson is worth more than the specific endpoint. An undocumented surface has no deprecation policy, because a deprecation policy is a promise, and nobody promised you anything.

Which Instagram API should you use?

If you have a choice, the choice is mostly about whether a Facebook Page is acceptable to your users. Meta's own comparison:

Capability	Instagram Login	Facebook Login for Business
Token type	Instagram User	Facebook User or Page
Facebook Page connection	Not required	Required
Comment moderation	Yes	Yes
Content publishing	Yes	Yes
Insights	Yes	Yes
Mentions	Yes	Yes
Hashtag search	No	Yes
Product tagging	No	Yes
Partnership ads	No	Yes

Instagram Login is the lower-friction option and the right default for most apps. Facebook Login for Business is what you need if hashtag search or commerce features are in scope, and it costs you a Facebook Page requirement that a lot of creators will not want to meet.

Can you get another account's data with business discovery?

This is the one outward-looking read Meta documents, and it is narrower than its reputation. The reference describes it in a single sentence:

"Returns data about another Instagram Business or Creator IG User."

What you get is a profile summary and its media: followers_count, media_count, and on the media edge comments_count, like_count and view_count. Meta notes that view_count "includes both paid and organic metrics," which matters if you are comparing accounts that advertise against accounts that do not.

The documented limitation is short: "Data about age-gated Instagram Business IG Users will not be returned."

Three practical constraints that the one-sentence description does not tell you:

1. Both ends must be professional accounts. You call it as an authorised Business or Creator account, and the target is documented as another Business or Creator account. Meta does not publish a sentence saying personal accounts are excluded, so treat that as what the documentation covers rather than as a stated prohibition.
2. Check which product exposes it before you design around it. Business discovery does not appear in Meta's own feature comparison between the two Instagram products, and its guide is filed under the Facebook Login product. Neither of those is a statement by Meta about availability, so confirm it against your own app's setup rather than against a blog post, this one included.
3. You get counts, never content. comments_count tells you how many comments a post has. No official endpoint gives you what they say.

What does the Hashtag Search API actually return?

An ID first, then media. You query a hashtag, get back a stable IG Hashtag object ID, and then read its top_media or recent_media edge. The IDs are universal: Meta's own example maps #bluebottle to 17843857450040591, and that number is the same for every app and every user.

The quota is the part to plan around:

"You can query a maximum of 30 unique hashtags on behalf of an Instagram Business or Creator Account within a rolling, 7 day period."

Repeat queries are free against that budget: "Subsequent queries on the same hashtag within this time frame will not count against your limit." So thirty is a ceiling on distinct hashtags per week per account, not on calls. If your product lets users type any hashtag they like, that ceiling is a design constraint, not a tuning parameter.

Also documented, and each one has caught somebody out:

• "You cannot comment on hashtagged media objects discovered through the API"
• "Hashtags on Stories are not supported"
• "Emojis in hashtag queries are not supported"
• "The API will return a generic error for any requests that include hashtags that we have deemed sensitive or offensive"

That last one returns a generic error rather than an empty result, which means a naive client cannot distinguish "no posts" from "we will not answer that."

Can you read comments on posts you do not own?

No. Comment moderation is scoped to media published by the professional account that authorised your app: read comments on your own media, reply to them, moderate them.

Two documented facts close the remaining doors. Media discovered through hashtag search is explicitly not commentable. And business discovery exposes comments_count on another account's media without exposing the comments. You can always learn how many, and never what they say.

One line in the comment moderation docs reads like an exception and is not. It says Advanced Access is needed "if your app serves Instagram professional accounts you don't own or manage." That is about which accounts are allowed to authorise your app, not about reading comments on posts nobody authorised you for.

What do the rate limits actually allow?

There are two different systems, and the interesting part is which endpoints fall under which.

Instagram Business Use Case limits are the ones people quote:

"Calls within 24 hours = 4800 * Number of Impressions"

Impressions means content impressions your app's accounts received in the last 24 hours. A busy account buys you a large budget. A quiet one does not.

Platform Rate Limits work on a completely different input:

"Calls within one hour = 200 * Number of Users"

Number of Users is derived from your app's unique daily active users, and Meta is explicit that this is a collective pool for the app rather than a per-user cap. One heavy user can consume budget that belonged to everyone.

Here is the detail that decides whether a product is feasible, and Meta states it in one line: "Business Discovery and Hashtag Search API are subject to Platform Rate Limits." The two endpoints that look outward at other people's accounts are metered against your own app's user count, not against the impressions your users' content earned. A small app gets a small pool for exactly the calls that do not depend on its own users' activity, which is the opposite of how most people size a competitive-research feature.

Three more published ceilings worth writing down:

Operation	Documented limit
Content publishing	100 API-published posts per 24-hour moving period
oEmbed	1,000 requests per hour
Conversations API	2 calls per second per professional account

Carousels count as a single published post, and GET /<IG_ID>/content_publishing_limit reports current usage, which is the correct way to schedule rather than counting in your own database.

Is Instagram oEmbed a way to read post data?

It returns real data, and Meta forecloses using it as a data source in one sentence:

"Using metadata and content for any purpose other than providing a front-end view is strictly prohibited"

It is also gated. The oEmbed Read feature "requires successful completion of the App Review process before your app can access live data" and "is only available with business verification." Private, inactive and age-restricted accounts are unsupported, as are Stories and accounts that disabled embeds.

So oEmbed is for rendering a post inside your page. If your plan was to call it in a loop and keep the JSON, the terms say no before the rate limit does.

What does Instagram's robots.txt say about scraping?

It is unusually direct, and it is worth reading before anyone on your team writes a fetch loop. The file opens with a notice:

"Collection of data on Instagram through automated means is prohibited unless you have express written permission from Instagram and may only be conducted for the limited purpose contained in said permission."

The rules underneath it:

• The catch-all is User-agent: * followed by Disallow: /.
• A named block fully disallows Amazonbot, Applebot-Extended, Brightbot, ClaudeBot, Google-Extended, GPTBot, PerplexityBot, PetalBot, Scrapy, uptimerobot, viberbot, YaK, Yandex and Yeti. The AI crawlers are named one by one, ClaudeBot, GPTBot, PerplexityBot and Google-Extended among them, which tells you what the file is currently defending against.
• Roughly twenty crawlers are allowlisted individually, including Googlebot, Bingbot, Applebot, DuckDuckBot, LinkedInBot, Twitterbot, Discordbot and Pinterestbot. Each gets the same narrow disallows: /ajax/, /direct/, /logging/, /publicapi/, /query/ and a few others.
• Googlebot and Bingbot alone are additionally blocked from /*/c/, /*/comments/ and /*/liked_by/, with Allow: /places/c/ carved back out.

And then the part that complicates the story: the same file declares sitemaps, including ig_seo_profile_sitemap.xml.gz. Instagram publishes profile sitemaps so search engines can index profiles, while disallowing everything for every crawler not on the list. Public to a search engine and closed to you is a coherent position for a platform to hold. It is just not the same thing as "this data is public."

One practical note if you go to read the file yourself: request it as a crawler. A browser-shaped user agent can be served the login shell instead of the text/plain file.

So what is actually available?

What you want	Official answer
Your own professional account's media and insights	Yes, both products
Another Business or Creator account's follower and media counts	Business discovery
Any personal account's posts	No
The comments on someone else's post	No
Search public posts by keyword	No
Media carrying a hashtag	Yes, 30 unique hashtags per rolling 7 days, professional accounts only
Embed a public post in your page	oEmbed, after App Review and business verification

If your use case is in the top two rows, use the official API. It is free, documented, versioned, and it will not break the week Meta ships a frontend change.

If it is in the bottom five, you have three options and they are all trade-offs. You can redesign the feature around what the API covers, which is the cheapest answer and the one nobody wants to hear. You can read the public web surface, which raises a contract question that turns entirely on whether anyone is logged in and which Instagram's robots.txt addresses in the paragraph quoted above. Or you can buy the data from a third party, in which case the thing to establish before you sign anything is how the vendor bills the requests that fail, because on a target this defended a meaningful share of them will.

Meta's newer network is a genuinely different answer, which is worth knowing before you assume the family is uniform. Threads does document endpoints that read public profiles and public posts belonging to other people, and they are gated in ways that decide whether they are usable. What the Threads API will and will not read is the companion to this page.

We sell an API that reads public Instagram data, so treat that paragraph as coming from an interested party. The documentation facts above are Meta's, and every one of them is linked below so you can check us.

---

Sources, all read 2026-09-12. Instagram Platform overview · Instagram API with Instagram Login · Changelog, for the Basic Display shutdown · business discovery reference · Hashtag search · Comment moderation · Content publishing · oEmbed · oEmbed Read feature gating · Platform rate limiting · instagram.com/robots.txt · Meta's Automated Data Collection Terms

Platform documentation in this category changes without notice. Archive anything you plan to rely on, and re-check the rate-limit pages before you size a product against them.