Instagram-private-api: Repeatedly receiving {"name":"ParseError","message":"Not possible to parse API response", "body": {"message": "Unknown Server Error.", "status": "fail"}}

[FrankTheDevop]

Hi everybody,
I am using the Library for roughly a year but in the last two weeks I encounter a behaviour I do not understand.
I have two setups:

1. Amazon AWS with Docker for Production with rented proxies
2. Local Docker Installation on my MacBook

I am using a forked Version from middle of September 2018 with a few changes. This was worked well until I started to receive {"name":"ParseError","message":"Not possible to parse API response", "body": {"message": "Unknown Server Error.", "status": "fail"}}.

It started randomly encountering that error. When I started investigating I quickly learned that I might mean I upload posts with the wrong measurements. So I added auto scaling to the publicly available ones.

The Problem remained.

I checked the format in which I send the data to the Instagram API, no problem found.

Yesterday I tried publishing a post in the morning and it failed. Later that day I tried again it worked. Both from AWS. When I tried it from my local machine it failed all the time, while using the same proxy.
First I thought the proxy isn´t used or blocked, but that is not the case.

I updated the library to the newest version here. Result: I always encounter {"name":"ParseError","message":"Not possible to parse API response", "body": {"message": "Unknown Server Error.", "status": "fail"}}.
After waiting a few hours and reverting to my old version with the same account I worked again for one post.

On my profile I get it like with most calls, on others it seems to be temporary and when I retry their task hours later it normally works. The System itself does only like 1 Post/Hour over multiple profiles. We are not using it for spamming but handling our own network of profiles.

Has anybody else experienced this? Do the Instagram Servers have currently temporary problems? Did they move from the distinct errors to this error so we don´t know how to react? Is this kind from a new kind of bot detection system that thinks my profile is a bot (I do less then one post per day on this profile and a max. of 2 posts 12 hours apart on others, every profile has another proxy)?

Kind Regards,
Frank

[oldwil19]

Hi everybody,
I am using the Library for roughly a year but in the last two weeks I encounter a behaviour I do not understand.
I have two setups:

1. Amazon AWS with Docker for Production with rented proxies
2. Local Docker Installation on my MacBook

I am using a forked Version from middle of September 2018 with a few changes. This was worked well until I started to receive {"name":"ParseError","message":"Not possible to parse API response", "body": {"message": "Unknown Server Error.", "status": "fail"}}.

It started randomly encountering that error. When I started investigating I quickly learned that I might mean I upload posts with the wrong measurements. So I added auto scaling to the publicly available ones.

The Problem remained.

I checked the format in which I send the data to the Instagram API, no problem found.

Yesterday I tried publishing a post in the morning and it failed. Later that day I tried again it worked. Both from AWS. When I tried it from my local machine it failed all the time, while using the same proxy.
First I thought the proxy isn´t used or blocked, but that is not the case.

I updated the library to the newest version here. Result: I always encounter {"name":"ParseError","message":"Not possible to parse API response", "body": {"message": "Unknown Server Error.", "status": "fail"}}.
After waiting a few hours and reverting to my old version with the same account I worked again for one post.

On my profile I get it like with most calls, on others it seems to be temporary and when I retry their task hours later it normally works. The System itself does only like 1 Post/Hour over multiple profiles. We are not using it for spamming but handling our own network of profiles.

Has anybody else experienced this? Do the Instagram Servers have currently temporary problems? Did they move from the distinct errors to this error so we don´t know how to react? Is this kind from a new kind of bot detection system that thinks my profile is a bot (I do less then one post per day on this profile and a max. of 2 posts 12 hours apart on others, every profile has another proxy)?

Kind Regards,
Frank

Hello man, we have similar problems since last week, actually, other people have similar problems.

[dilame]

Instagram is constantly updating its API, and this repository needs collaborators, because i don't have enough time for all that work.
So if somebody have newest unpinned APK, i appreciate if you share it with me.
If you forked this library and modified it, please, send a PR.

[oldwil19]

Instagram is constantly updating its API, and this repository needs collaborators because I don't have enough time for all that work.
So if somebody has newest unpinned APK, I appreciate if you share it with me.
If you forked this library and modified it, please, send a PR.

Hey man, I wish to help you. maybe we can look this repo https://github.com/ping/instagram_private_api
They use graphql Instagram for example. @dilame

[electronic33]

Hey! I'm getting the same error, is there any workaround? Is there a fix being worked on? Thanks in advance!

[FrankTheDevop]

Hi @electronic33,

I haven´t found one yet. I was trying another library (https://github.com/mgp25/Instagram-API) to see
if I can make it work (hail to microservices). The problem there is that it has another cookie data format and so it´s a new login, which seems to ring the alarm bells of Instagram (even with the same proxy configuration).
With one profile it worked and I saw they use another url. They seemed to use a resumable upload but that is all I can find out so far (src/Request/Internal.php L1576-1580):
$endpoint = sprintf('https://i.instagram.com/rupload_igphoto/%s_%d_%d',
$internalMetadata->getUploadId(),
0,
Utils::hashCode($photoDetails->getFilename())
);
Edit: What I forgot to mention is that even in that library I can´t add userTags. When I try to do it in the way their documentation/examples or the examples here show then I receive the same error as mentioned in the title.

Kind Regards,
Frank

[electronic33]

@FrankTheDevop Thanks for the quick reaction! In my case I was uploading photos using a cron, and the exact same code worked last week, now it doesn't :(

The problem there is that it has another cookie data format and so it´s a new login, which seems to ring the alarm bells of Instagram (even with the same proxy configuration).

Are you saying that they (Instagram) can deny these requests made through this library? If you find a workaround - best case would be using this library - please let me know.
Here is the code that uploads the photos in my codebase:

const upload = await instagramClient.Upload.photo(session, config.TMP_PATH + finalImageName);
await instagramClient.Media.configurePhoto(session, upload.params.uploadId, `"${clearString(title)}" ${config.HASHTAGS}`);

Edit 1: format

[FrankTheDevop]

@electronic33

@FrankTheDevop Thanks for the quick reaction! In my case I was uploading photos using a cron, and the exact same code worked last week, now it doesn't :(

I hear you brother. I have experienced the exact same thing. That is why (after trying to debug it) I temporarily replaced this part of my stack with another solution.

The problem there is that it has another cookie data format and so it´s a new login, which seems to ring the alarm bells of Instagram (even with the same proxy configuration).

Are you saying that they (Instagram) can deny these requests made through this library? If you find a workaround - best case would be using this library - please let me know.
Here is the code that uploads the photos in my codebase:

I am saying that Instagram evolves and something on the requests we do stops us from configuring the pictures. Uploads are fine.
I was unable to find a workaround with this library, I checked it´s updates daily and nothings seemed to help.
I´m very grateful to have made the decision to implement a microservice and message based stack. This allowed me to implement a workaround with the other library. Currently posting pictures is the one part where I use it.