Instead, I was looking at login errors.

Again.

All I wanted was a reliable way to save copies of my own Instagram posts, stories, and highlights. Somehow, I'd ended up spending more time maintaining the Instagram client than working on the backup process itself.

That was the point when I started reconsidering my setup.

Why I Started With instagrapi

My original approach used instagrapi, an unofficial Python Instagram client.

It seemed like a reasonable choice. I already used Python, wanted control over the backup process, and preferred running everything locally.

The basic setup was straightforward:

from instagrapi import Client

cl = Client()
cl.login("username", "password")

user_id = cl.user_id_from_username("username")

posts = cl.user_medias(user_id, amount=20)

for post in posts:
    print(post.pk, post.caption_text)

The attraction was obvious. I could access media information, download content, and organize backups using ordinary Python scripts.

For a personal backup workflow, that was pretty appealing.

I could also add scheduling, local storage, and metadata tracking without building a complicated application.

The problem wasn't writing the initial script.

It was keeping it working.

The Maintenance Problem

instagrapi interacts with Instagram through unofficial interfaces. That means changes to Instagram's private endpoints, authentication behavior, or request validation can affect the client.

I started treating authentication as another part of the application that needed ongoing attention.

A typical maintenance session involved checking whether a problem came from:

• An expired or invalid session
• A login challenge or verification requirement
• Request throttling
• Changes to Instagram's internal endpoints
• A client-library compatibility issue

These are not necessarily bugs in instagrapi. They're consequences of relying on an unofficial interface to a platform that can change its behavior.

Session persistence helped reduce repeated logins:

from instagrapi import Client
from pathlib import Path

cl = Client()
session_file = Path("session.json")

if session_file.exists():
    cl.load_settings(session_file)

cl.login("username", "password")
cl.dump_settings(session_file)

But persisting a session isn't a guarantee that Instagram will continue accepting it. Session files also contain sensitive authentication information and need to be protected.

I was building a backup utility, not an authentication maintenance project.

Yet that was increasingly what the project felt like.

Switching to a Hosted REST API

I eventually looked at HikerAPI as an alternative.

It's a hosted REST API for accessing Instagram-related data. Instead of running an Instagram client with its own session and authentication handling, my Python application sends HTTP requests to an API service.

The pricing model also made it practical to evaluate for a small project: requests start at $0.001 each, with 100 free requests available.

That pricing isn't necessarily what every endpoint costs, so I'd still check endpoint-specific pricing before estimating a backup budget.

The main reason I was interested wasn't the price, though.

It was the opportunity to move some of the Instagram integration maintenance outside my own application.

Making My First API Requests

I started with simple requests to understand authentication, response structures, and identifiers.

Here's an example that resolves a public username and then requests follower data:

import requests

headers = {"x-access-key": "YOUR_KEY"}
user = requests.get("https://api.hikerapi.com/v2/user/by/username?username=nike", headers=headers).json()
resp = requests.get(f"https://api.hikerapi.com/v2/user/followers?user_id={user['pk']}", headers=headers)
print(resp.json())

This example isn't my backup implementation. It demonstrates the basic request pattern using a public account.

For my actual use case, follower lists aren't particularly useful. I care about media, captions, timestamps, story assets, and highlight collections.

The useful change was architectural: I could separate API requests from the code responsible for organizing and storing my backups.

I also wanted better error handling than immediately calling .json() on every response.

For example:

import os
import requests

API_BASE = "https://api.hikerapi.com/v2"

session = requests.Session()
session.headers.update({
    "x-access-key": os.environ["HIKERAPI_KEY"]
})

def api_get(path, params=None):
    response = session.get(
        f"{API_BASE}/{path.lstrip('/')}",
        params=params,
        timeout=30
    )

    response.raise_for_status()
    return response.json()

profile = api_get(
    "user/by/username",
    {"username": "nike"}
)

print(profile.get("pk"))

For a production script, I'd additionally handle timeouts, rate-limit responses, response validation, and carefully bounded retries.

I'd also keep the API key out of source control.

Designing the Backup Workflow

My goal was to keep the backup process simple and make its output independent of whichever Instagram data provider I used.

The structure I settled on conceptually was:

Instagram data provider
         |
         v
   API response
         |
         v
 Metadata normalization
         |
         v
  Backup manifest
         |
         v
 Local media storage
         |
         v
  Backup verification

Posts, stories, and highlights have different characteristics.

Posts are relatively straightforward to archive incrementally. I can use stable media identifiers to avoid saving the same item repeatedly.

Stories are more complicated because they're temporary. If the backup process doesn't run while a story is accessible, the opportunity to retrieve it may be lost.

Highlights need separate treatment because they're collections that can change over time.

I also need to verify which media endpoints, permissions, and content types the provider actually supports. Accessing profile information doesn't automatically mean every story or highlight asset is available.

A backup system should not claim something was archived merely because an API request succeeded.

Making the Backup Idempotent

One thing I wanted to preserve from my self-hosted approach was control over the resulting files.

The ingestion layer can change, but the backup format shouldn't have to.

Here's a simplified local storage function:

import json
from pathlib import Path
from datetime import datetime, timezone

BACKUP_DIR = Path("instagram_backup")
BACKUP_DIR.mkdir(exist_ok=True)

def save_metadata(media_id, metadata):
    file_path = BACKUP_DIR / f"{media_id}.json"

    if file_path.exists():
        return False

    record = {
        "media_id": str(media_id),
        "backed_up_at": datetime.now(
            timezone.utc
        ).isoformat(),
        "metadata": metadata
    }

    file_path.write_text(
        json.dumps(record, indent=2),
        encoding="utf-8"
    )

    return True

This makes repeated processing safer because previously archived identifiers won't generate duplicate metadata files.

It is only a starting point, though.

For proper backups, I would also want to:

• Download the original accessible media files rather than saving metadata alone.
• Verify downloads using file sizes or checksums.
• Track failed downloads for later retries.
• Store story capture timestamps.
• Maintain a manifest of completed and incomplete items.
• Account for edited captions or other changing metadata.

The distinction between retrieved, downloaded, and verified matters.

A successful JSON response is not a successful media backup.

What About Instagram Bans?

This was one of the bigger reasons I reconsidered my original approach.

With a self-hosted client, my application directly manages unofficial Instagram interactions. Repeated authentication attempts, unusual activity patterns, or automated requests can trigger restrictions, checkpoints, or temporary blocks.

Using a hosted API changes the operational model, but it doesn't make platform restrictions disappear.

There are still important limitations:

A hosted service is not automatically an official Instagram API. Its access methods may still depend on unofficial interfaces and can be affected by Instagram changes.

Provider infrastructure can be restricted too. I might avoid maintaining Instagram sessions locally, but that doesn't guarantee the provider will always have access.

Data coverage can vary. Public profile access doesn't imply private content, stories, highlights, or every media format will be retrievable.

Terms and permissions still matter. A third-party service doesn't remove my responsibility to consider Instagram's terms, privacy, and authorized access.

For backing up my own content, I'd still prefer official Instagram export functionality as an independent fallback.

The benefit of switching wasn't that bans became impossible.

It was that I no longer needed to own every piece of the unofficial client maintenance process.

That's a meaningful distinction.

The Cost Tradeoff

Self-hosting can look free because there's no charge per request.

But free requests don't necessarily mean free operations.

With instagrapi, my costs included maintaining the scripts, dealing with authentication problems, monitoring failures, and troubleshooting compatibility issues.

A hosted API introduces direct request charges instead.

For a small personal backup project, that might be reasonable. For frequent polling or large-scale archival, API usage can become a significant expense.

It also introduces external dependencies: provider availability, billing, endpoint changes, and service limits.

I wouldn't choose one approach solely because the request price looked low.

I'd compare the cost of the actual endpoints needed for posts, stories, and highlights against the maintenance work I'm trying to avoid.

What I Gained and What I Gave Up

Here's how I think about the tradeoff now:

The biggest thing I gave up was direct control over the Instagram interaction layer.

The biggest thing I gained was a simpler application boundary.

I could spend more time working on backup integrity, media organization, and recovery, rather than trying to understand why an authentication flow had changed.

Would I Switch Again?

For a personal Instagram backup workflow, I prefer keeping the data collection layer replaceable.

I don't want the entire backup system tied to one Python library or one hosted provider.

If a provider becomes unavailable, changes its pricing, or stops supporting an endpoint I need, I should be able to change the ingestion code without reorganizing years of stored files.

I also wouldn't rely exclusively on an unofficial integration for important personal content. Official exports and independently verified local backups remain valuable.

The switch from instagrapi to a hosted REST interface is primarily an engineering tradeoff: less direct maintenance, more dependency on an external service.

For my use case, that tradeoff makes sense.

And, ideally, the next time I sit down with coffee to check my backups, I'll be checking whether the files were saved correctly rather than debugging another login challenge.