Instagram API libraries by language: what's actually maintained in 2026

If you searched for an Instagram API library in your language of choice, the GitHub topic page (/topics/instagram-api) probably gave you something with a few hundred stars and an upbeat README. The catch in 2026 is that “has stars” and “still works” have drifted apart for almost every language other than Python. Instagram’s private API has shifted enough times — login flow, challenge handling, encryption, write surface — that any library not actively shipping releases is, in practice, broken on first contact. This page is a survey: who’s alive in each language, who’s archived or stale, and the two cross-language patterns that work when your language has nothing maintained.

TL;DR

In Python, instagrapi is actively maintained and is the safe default. In Java, instagram4j is the one alive option. In PHP there are two libraries still receiving updates, both slowing. In Node.js, Go, C#, Swift and Ruby, the most-starred libraries are either archived outright or have not seen a meaningful release in well over a year. The two cross-language exits are running instagrapi-rest as an HTTP sidecar (you keep the infra, you bring any language), or using HikerAPI as a managed service (no infra, any language).

At a glance

The table below uses GitHub’s pushedAt as the signal. Anything older than ~12 months is marked stale; anything explicitly archived is marked archived; anything with regular pushes is marked active. Star counts are point-in-time as of May 2026.

Language	Library	Stars	Last push	Status
Python	subzeroid/instagrapi	6 130	2026	✅ active
Python	subzeroid/aiograpi	346	2026	✅ active (async)
Python	ping/instagram_private_api	3 254	2024-05	⚠️ stale
Python	diezo/Ensta	455	2026-01	✅ active (small)
Node / TS	dilame/instagram-private-api	6 429	2024-08	⚠️ stale
PHP	postaddictme/instagram-php-scraper	3 281	2025-05	⚠️ slowing
PHP	pgrimaud/instagram-user-feed	939	2024-05	⚠️ stale
Java	instagram4j/instagram4j	946	2026-04	✅ active
Java	postaddictme/instagram-java-scraper	473	2023-03	📦 archived
Go	ahmdrz/goinsta	896	2021-07	📦 archived
C#	ramtinak/InstagramApiSharp	883	2025-05	⚠️ slowing
C#	a-legotin/InstaSharper	517	2024-04	⚠️ stale
Swift	sbertix/Swiftagram	257	2022-12	⚠️ stale
Swift	AnderGoig/SwiftInstagram	576	2018-10	📦 archived
Ruby	eVanilla/instabot.rb	155	2018-11	📦 effectively dead

Python — the only language with an active wrapper at scale

instagrapi is the working answer in Python. Active releases, full write surface (post, DM, story, comment), pydantic-typed responses, first-class challenge_required and 2FA handling. aiograpi is the same project’s async fork, same API shape — the sync vs async guide covers when to switch. ping/instagram_private_api is the older library that the early Python Instagram community grew up on; the last push was May 2024, and several issue threads about login breakage are open and unanswered. diezo/Ensta is a smaller maintained alternative — narrower surface, single-developer, but actively shipping.

For new code, default to instagrapi. For an existing ping/instagram_private_api codebase, the migration cost is real but the library shapes are similar enough that it is mostly a search-and-replace job.

Node.js / TypeScript — dilame/instagram-private-api froze in mid-2024

dilame/instagram-private-api has the second-highest star count on the entire instagram-api topic — 6 429 ⭐ — and the last push to the repository was August 2024. Star momentum from 2018-2022 is doing the work; the codebase is not. If you are starting a Node project today and pin instagram-private-api, your code will compile and you will hit challenge_required or a login error on the first non-trivial call. The issue tracker reflects this: the open issues that map to “logged out, can you log me back in” outnumber active development by a wide margin.

There is no actively-maintained drop-in replacement in pure Node. The two paths that work are running instagrapi-rest from your Node service, or moving the Instagram-facing surface entirely to HikerAPI and keeping the rest of your stack in Node.

PHP — two libraries, both slowing

PHP is the second-best-served ecosystem after Python, but the trend line is downward. postaddictme/instagram-php-scraper (3 281 ⭐) is the largest and was last pushed in May 2025 — about a year stale at time of writing, but neither dead nor archived. pgrimaud/instagram-user-feed (939 ⭐) is older with a similar update cadence. Both projects address public-profile scraping rather than the full mobile-API surface that instagrapi covers. If your job ends at “fetch a public profile, list recent posts,” either is workable; if you need login, posting, or DMs from PHP, the cross-language exits are the more reliable path.

Java — instagram4j is the only alive option

instagram4j/instagram4j is the bright spot outside Python. Active commits in 2026, full mobile-API surface, object-oriented design that maps cleanly to Java idioms. postaddictme/instagram-java-scraper is the older alternative and is archived since 2023. If you are on the JVM, instagram4j is the right starting point. If your stack is on the JVM but Kotlin / Scala / Clojure rather than Java, the same library imports cleanly.

Go — nothing maintained

ahmdrz/goinsta (896 ⭐) is the canonical Go Instagram library and was archived in July 2021. There is no maintained successor with meaningful star count. If you need Instagram from Go in 2026, your two options are the cross-language patterns described below; writing a new wrapper from scratch against the current Instagram private-API surface is a multi-month engineering project that needs continuous maintenance.

C# / .NET — the slow death

Both serious .NET options — ramtinak/InstagramApiSharp (883 ⭐) and a-legotin/InstaSharper (517 ⭐) — are slowing. ApiSharp’s last push was May 2025; InstaSharper’s was April 2024. Neither is archived, but the activity gap against instagrapi (which ships within days of Instagram surface changes) is wide enough that you will start hitting silent breakage if you depend on either for production.

Swift — gone

AnderGoig/SwiftInstagram (576 ⭐) was archived years ago; the last commit is from 2018. sbertix/Swiftagram (257 ⭐) is the more modern option but the last push is December 2022. There is no active Swift wrapper for Instagram’s private API. iOS and macOS apps that need Instagram data should reach for the cross-language patterns.

Ruby and others — never really had one

eVanilla/instabot.rb is the single Ruby option you will find on the topic page; the last commit is 2018. Other languages (Elixir, Rust, Crystal, R) have no library worth naming. If you are on these stacks and need Instagram data, you are picking between writing your own wrapper, running instagrapi-rest, or using HikerAPI.

Cross-language exit #1 — instagrapi-rest as a sidecar

instagrapi-rest is instagrapi wrapped as a FastAPI service. Run it as a Docker container next to your application — same machine, private network — and call it over HTTP from whatever language your app lives in. You get instagrapi’s endpoint surface and release cadence without writing any Python code yourself. The trade-off is that you are still running the infrastructure: the instagrapi-rest container handles the Instagram session, proxy, and challenge state, and you are responsible for keeping it up, rotating IPs, and storing the session blob.

# docker-compose.yml — instagrapi-rest as a sidecar to your service
services:
  instagrapi-rest:
    image: subzeroid/instagrapi-rest:latest
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - ./sessions:/app/sessions

  your-app:
    build: .
    environment:
      INSTAGRAM_API_URL: http://instagrapi-rest:8000
    depends_on:
      - instagrapi-rest

For most non-Python services this is the cheapest path: one container, one HTTP dependency, no language switch.

Cross-language exit #2 — HikerAPI as a managed service

HikerAPI exposes the same Instagram private-API surface as a managed HTTPS endpoint with an API key. There is no container to run, no session blob to store, no proxy pool to rotate. The trade-off is you are paying per request rather than running infra, and your data path now goes through a third party. For services that already pay for managed databases, managed queues, and managed observability, paying for managed Instagram access is the same shape of decision.

The same HIKERAPI_KEY works from Node, Go, PHP, Java, C#, Swift, Ruby — anything that can make an HTTPS request. There is also a public MCP server for AI-agent contexts that need Instagram tools without writing client code.

When to pick which path

If your stack is already Python, use instagrapi directly and read the migration / framework guides for your specific runtime (Django, FastAPI, Celery, Docker, AWS Lambda).

If your stack is on the JVM and you have Java, Kotlin or Scala in your toolbox, instagram4j is the working library. If you would rather not introduce another moving part, the sidecar pattern still applies.

If your stack is anything else — Node, Go, PHP-with-write-needs, C#, Swift, Ruby — pick between the two cross-language exits based on whether you want to run the Instagram-facing infrastructure yourself (instagrapi-rest) or pay someone to run it for you (HikerAPI). The functional surface is the same; the operational shape is different.

Wrapping up

The healthy ecosystem story for Instagram libraries is mostly a Python story. Outside Python, the most-starred result on /topics/instagram-api is almost certainly stale or archived — the topic ranks by stars, and stars do not lapse when commits do. If you have a non-Python codebase, plan for the Instagram-facing surface to live behind an HTTP boundary you control (instagrapi-rest) or a managed one you do not (HikerAPI), so that the language you write your business logic in stays decoupled from whoever happens to be maintaining a wrapper this quarter.