admin管理员组

文章数量:1400161

There are a couple of unresolved questions about the same issue:

  • Imgur API - Getting "Too many Request" error even though 'X-Ratelimit-Userremaining' is not 0
  • imgur API: UserRemaining at 0 and never resets
  • Imgur API BUG Too many Requests by image upload

There are answers offered, but I can't figure out how to make use of them. I'm hoping to get a better answer with more info here.

I started out using the imgurpython library, but it stopped working for me some months back. Just recently I tried switching to pyimgur. Now I'm just trying to get even simple GETs for info (e.g. album contents) to work. Notably, I was able to upload an image anonymously with Pyimgur, so the basic code works. I was also able to query my account and get a list of my albums and their IDs.

I've authenticated, and I have an access token and refresh token. I can use the refresh token to get a new access token. I can use the access token to check credits (in Postman):

{
    "data": {
        "UserLimit": 2000,
        "UserRemaining": 2000,
        "UserReset": 1742844405,
        "ClientLimit": 12500,
        "ClientRemaining": 12494
    },
    "success": true,
    "status": 200
}

However, if I try to use GET album against one of my album IDs, it fails with a 429 and the header say I have no credits (GET /[id]):

{
    "errors": [
        {
            "id": "legacy-api-7dd44684d9-xwlll/l1bBIDuZQR-7470825",
            "code": "429",
            "status": "Too Many Requests",
            "detail": "Too Many Requests"
        }
    ]
}
X-Ratelimit-Clientlimit
    12500
X-Ratelimit-Clientremaining
    12499
X-Ratelimit-Clientreset
    86400
X-Ratelimit-Userlimit
    2000
X-Ratelimit-Userremaining
    0
X-Ratelimit-Userreset
    3600

The album ID is correct - it's straight from the query showing all the albums in my account. I can access the album correctly via /[id]. It's hidden, but not private - I can view it in incognito. I've tried both authenticating with my access token using Bearer, and just with the client ID. Neither work, both give the same error.

I tried pulling a random gallery from the front page and for some reason that does work (GET ):

{
    "data": {
        "id": "XhgWATV",
        "title": "Cat wearing Warhammer 40k helmet",
        "description": null,
        "datetime": 1742830153,
        "cover": "yMV5kFR",
        "cover_width": 508,
        "cover_height": 854,
        "account_url": "wolfwinter",
        "account_id": 61611821,
        "privacy": "hidden",
        "layout": "blog",
        "views": 6900,
        "link": ";,
...

For this query, X-Ratelimit-Userremaining is slightly below 2000 as expected.

I see that this output gives a link showing the same ID as an album link, so I try plugging that into a query against album/XhgWATV and I again get a 429. So, is the problem that I need to use a gallery rather than an album?

But I try querying my own album ID against a gallery instead and it gives me a 404!

So it seems like any query against an album will get this misleading rate limit error, even while the rate limit ticks down correctly for requests to galleries. I also get a 429 for images, whether from my own album, or the image from the public gallery I can query ().

I'm using Postman to make these requests. The above related questions have some mentions of Podman config issues in the answers, but I tried the same thing using HTTPie in my browser and saw the same behaviour.

For the sake of having a specific image/album to use for comparison I uploaded a free image and am hitting the same issues with it:

My end goal is simple: I want to be able to use pyimgur (or imgurpython (or really anything!)) to programmatically upload images, put them in albums, and query the contents of those albums. Each part of that process seems to be broken for some reason. (Needless to say that uploads and album creation also hit these 429 errors.) Did Imgur silently break the API in the last few months? It doesn't seem that the problem in general is new, even if I wasn't hitting it until recently.

本文标签: