I've just implemented this module in a customer site and it works just fine locally. When porting everything to the live site the Guzzle requests to Instagram respond with a 429 which indicates too many requests per hour.

When calling wget https://www.instagram.com/username/ on the command line of the server, I also get the 429 response but when doing that from the local desktop I do receive the correct html content from Instagram.

That feels like if the limit is per source IP? But that's strange too because I haven't used many requests from the live server so I'm really confused and hope someone can help me with this.

BTW, it doesn't matter which username I use, it is for any username the same problem.

Comments

jurgenhaas created an issue. See original summary.

jurgenhaas’s picture

Hmm, strange is the word ....

Found out that on the live host www.instagram.com resolved to 157.240.20.174 where as locally it resolved to 185.60.216.174. Now I forced the same IP address also to the live host and then it is working just fine.

edysmp’s picture

malcomio’s picture

See also #3205131: Instagram CORS blocking functionality for a similar issue on the Drupal 7 version.

ipwa’s picture

Status: Active » Fixed

window._sharedData scraping was replaced with Instagram's web_profile_info JSON endpoint (with the old HTML scrape kept as a fallback). The module now uses https://www.instagram.com/api/v1/users/web_profile_info/?username={name} with X-IG-App-ID: 936619743392459 header as the primary data source.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

ipwa’s picture

Version: 8.x-1.0 » 8.x-2.x-dev
ipwa’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.