instagrapi vs instabot: which Python Instagram automation library is alive?

I wrote instabot (and its predecessor igbot) starting around 2018. The pip package was published from my account, and the repo lives at ohld/igbot. I retired it in favor of instagrapi after Instagram broke the private-API mobile flow once too many — keeping a single library current became a treadmill. If you have legacy code on instabot, this guide is your migration path.

TL;DR

instabot and instagrapi are both Python wrappers around Instagram’s private mobile API, but only one of them is actually keeping up with Instagram. instabot was a popular choice in the late 2010s — the README is still well-known, the import is short, and example snippets are everywhere. The problem is that Instagram has rotated its login flow, challenge handling, and write endpoints many times since instabot’s last meaningful release, and the project hasn’t tracked those changes. For any new code in 2026, instagrapi is the only practical pick. The rest of this guide goes through the maintenance signals, the current API gap, and how to migrate without rewriting your business logic.

Maintenance signals

If you’re evaluating an open-source library, the GitHub project page tells you almost everything you need to know in thirty seconds. For instabot, the picture has been the same for a while: the most recent releases on PyPI are years old, the issue tracker is dominated by login-broken reports that stay open, and pull requests addressing those reports do not appear to land. None of that is a moral judgment — maintainers move on, projects calcify — it’s just the observable state.

instagrapi, by contrast, is actively maintained. Releases ship on PyPI on a regular cadence, the issue tracker shows triage activity within days rather than years, and the codebase tracks Instagram’s mobile API as it shifts. You don’t have to take anyone’s word for this; both projects are public, and a five-minute scan of commits, releases, and issue close rates will confirm the gap.

For an Instagram library specifically, this gap matters more than for most dependencies. Instagram changes its private API surface continuously. A library that hasn’t shipped in years isn’t “stable” in the boring-good sense; it’s frozen against a target that has already moved.

API coverage today

The two libraries set out to solve the same general problem — wrap the Instagram private mobile API in idiomatic Python — and on paper the surface is similar. In practice, the gap is large and growing, because most of instabot’s endpoints depend on a working login flow, and that login flow is the most-broken piece of instabot today. The table below is a snapshot of where things stand for new code; treat the partial and broken markers as “users currently report this not working” rather than “the API doesn’t exist.”

Capability	instagrapi	instabot
Login + session reuse	✅	⚠️ frequently broken
2FA / challenge handler	✅	❌
Posting (photo/video/reel)	✅	partial / broken
Direct messages	✅	partial
Stories	✅	partial
pydantic-typed responses	✅	❌
Active community	✅	minimal

The practical impact of this table is harsher than it looks. Almost every useful operation on Instagram requires a logged-in session: posting, DMs, follows, likes, story uploads, hashtag walks beyond the public surface. If login is unreliable, every feature downstream of login is unreliable too. With instabot, that cascade is the dominant failure mode reported by users — the script runs, hits bot.login(), and either gets a generic exception or sails through and then fails on the first authenticated call. There is no hardened challenge_required path, no first-class 2FA flow, and no way to plug in a custom challenge handler. With instagrapi, those are first-class features and have been for years.

Migration walkthrough

Migrating an existing instabot script to instagrapi is mostly mechanical. The verbs are the same — log in, follow a user, like a post, send a DM — and the sequencing is the same. What changes is the import, the client class, and a handful of method names. Below is a side-by-side of the most common starting point: log in, then follow @instagram. Note that instabot’s import names varied across versions; the snippet here is representative.

# instabot (representative — actual import names vary by version)
from instabot import Bot
bot = Bot()
bot.login(username="...", password="...")
bot.follow("instagram")

# instagrapi
from instagrapi import Client
cl = Client()
cl.load_settings("session.json")  # session reuse
cl.login("...", "...")
cl.user_follow(cl.user_id_from_username("instagram"))

Two things are worth pointing out. First, instagrapi separates “resolve username to user_id” from “follow that user_id,” which is closer to how the actual mobile API works and means you can cache user_ids for repeated calls. Second, load_settings plus login is the recommended pattern: persist your device fingerprint and cookie jar across runs, so Instagram’s risk system sees a stable device rather than a fresh login every time. That single change is the biggest reliability win when moving off instabot.

If you find this guide via ohld/igbot, welcome — and yes, same author.

Wrapping up

For any new project in 2026, instagrapi is the right choice — it is actively maintained, tracks Instagram’s private API, and has first-class 2FA and challenge handling that instabot never grew. If you have an existing instabot codebase, the migration path is short: swap the import, rename the client, and adopt session persistence with load_settings / dump_settings. The install guide walks through pip install and the first session, and the 2FA and challenge guide covers the login hardening you’ll want before a script goes anywhere near production.