# Building an Instagram OSINT Project on Fedora Linux

davidf] — Sun, 16 Aug 2026 07:28:26 +0000

Building an Instagram OSINT Project on Fedora Linux

I'm building an Instagram OSINT project on Fedora Linux using Python and Osintgram. The goal is to experiment with retrieving publicly available Instagram profile and post information while keeping the project organized as a local development environment.

Why I Started Building It

I wanted to experiment with how an OSINT tool could collect publicly available Instagram information and organize the results in a useful way.

I started with Osintgram because it already provides a CLI-based foundation for Instagram OSINT. While setting it up, I ran into authentication problems with Instagram's direct login.

The same credentials worked normally through Instagram, but the automated login returned a bad_password response. That was harder than expected because I initially assumed the authentication behavior would be the same.

That pushed me toward testing an API-based data layer.

Testing HikerAPI

For the data source, I'm experimenting with HikerAPI, a hosted REST API for Instagram data.

The basic request I'm testing looks like this:

import requests

headers = {"x-access-key": "YOUR_KEY"}

user = requests.get(
    "https://api.hikerapi.com/v2/user/by/username?username=nasa",
    headers=headers
).json()

resp = requests.get(
    f"https://api.hikerapi.com/v2/user/stories?user_id={user['pk']}",
    headers=headers
)
print(resp.json())

The part I like about this approach is that the application can interact with a defined REST interface instead of having to handle all of the underlying data-collection logic itself.

The Hardest Part So Far

The hardest part has been authentication.

I originally expected that because my Instagram credentials worked normally, Osintgram would be able to authenticate with them as well. That wasn't the case.

It made me realize that authentication for an automated client can behave differently from authentication through the normal application.

That experience is one of the reasons I'm separating the data-collection layer from the rest of the project.

Where the Project Is Going

I'm still building and testing the project, so I don't want to claim that I've already solved every reliability or data-collection problem.

Right now I'm interested in keeping the project modular. Ideally, the rest of the application shouldn't need to care whether data comes from one API, another API, or another collection method.

I'm also paying attention to things like request limits, error handling, and what happens when an API request fails.

The goal isn't just to get one successful request. I want to understand how to build the surrounding application so it can handle the data-collection layer cleanly.

What I'm Learning

The biggest lesson so far is that the interesting part isn't necessarily making an API request.

It's everything around it: authentication, errors, rate limits, organizing the returned data, and designing the application so one external dependency doesn't dictate the entire architecture.

I'm still working on the project and testing different approaches.

If you've built an OSINT or web-data project before, how would you structure the data-collection layer?