From Termux to a Freestyle VM: My Osintgram and HikerAPI Experiment

From Termux to a Freestyle VM: My Osintgram and HikerAPI Experiment

After experimenting with Osintgram directly in Termux, I wanted to see how the same project behaved inside a Linux environment running through a Freestyle VM.

The idea was not simply to reproduce the installation. I wanted to understand whether moving the project into the VM would make the HikerAPI troubleshooting any clearer.

Why use a VM?

Termux is capable of running many command-line tools directly on Android, but a VM provides a more conventional Linux environment.

I connected to the Freestyle VM from Termux and worked with Osintgram from there.

The project could start, but the API side still required investigation.

The dependency confusion

One of the first things I noticed was that there were multiple API-related components involved.

I initially looked at the installed "hikerapi" package and its "Client" class.

That alone wasn't enough to explain what Osintgram was doing.

So I switched from inspecting only the Python environment to inspecting the project's source code.

The HikerAPI-related code pointed me toward:

src/hikercli.py

This was much more informative because it showed where the client was being configured and how the access token entered the application.

Checking the installed library

I also checked the installed HikerAPI package rather than assuming I had the expected version.

For example:

python3 -m pip show hikerapi

This let me verify the package that was actually installed in the VM.

The important point here is that checking a package version and understanding how the application uses that package are two different troubleshooting steps.

Separating authentication from Osintgram

I found it useful to test the API independently instead of using Osintgram as the only diagnostic tool.

For example:

import requests

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

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

print(r.json())

Again, "YOUR_KEY" is only a placeholder. A real API key should remain private.

This smaller test gave me a cleaner way to distinguish an application configuration problem from an API-account problem.

What the errors told me

The troubleshooting produced two different stages.

At first, the request produced an unauthorized response.

After correcting the token configuration, the response changed and HikerAPI reported that the account needed additional credit.

That was actually useful information.

Instead of continuing to change Python packages blindly, I could now identify that the remaining blocker was associated with the HikerAPI account rather than simply the VM or Python installation.

The main lesson

The biggest lesson from moving the project into the VM was that a more powerful environment does not automatically solve an integration problem.

The Freestyle VM gave me a Linux environment, but I still needed to understand the application's source code and the API authentication flow.

For debugging projects like this, I found this order much more useful:

1. Verify the Python environment.
2. Check the installed dependency.
3. Inspect the application's API integration.
4. Test the API separately.
5. Interpret the resulting error before changing more things.

That approach made the problem much easier to narrow down.

Where I ended up

The experiment successfully helped me identify the difference between an authentication/configuration problem and the later account-credit response.

I would not describe the project as completely finished, because the HikerAPI account-credit requirement still prevents the API-dependent functionality from being fully tested.

However, the troubleshooting process itself was valuable.

It gave me a better understanding of how Osintgram's API components fit together and showed me why reading the source code can be more useful than repeatedly reinstalling dependencies.

If you're working with Python applications that depend on external APIs, isolate the API request first. It can save a lot of time when determining which part of the stack is actually failing.