DM Image proxy & rate limiting



In our application we allow customers to manage multiple social channels in one place for a team of social media managers. One of these social channels are Mentions and DMs of Twitter accounts.

Since this was introduced it is no longer possible to simply display images from DMs as requests to those now have to be signed. In the post linked above you propose the following solution: Implement a backend route that basically acts as image proxy – so instead of having the browser request the image directly, the DM image URL is passed to our own HTTP server that checks whether the client has access to the channel using our own authentication method and then a signed OAuth request is made and the image is passed through to the client.

This is not a viable solution though, because as explained in the link above you seem to apply rate limiting to all signed requests. This means that after loading several images / or loading the same image repeatedly – any further Twitter API requests will be blocked. Meaning that not only the DM images do no longer work, but we can’t even make any other API requests for synchronizing our system with Twitter.

  • Do you have any plans on working on this issue?
  • How do you expect us to deal with this in the meantime?

Thank you


Hey @patrickd_de.

Have you read through our ‘Tips to avoid being Rate Limited’ docs section? The caching suggestions might help you avoid hitting rate limits here.

Let me know if this helps. We can explore other solutions if not.


Hi @LeBraat, thank you for taking the time.

Yes, we’ve also considered implementing an image cache to prevent wasting API hits by loading the same image.

Even so we hit the limit during testing rather quickly and I don’t see the exact rate limit documented anywhere for the DM images. Moreover we’re worried that we might hit app or user scoped limits by fetching to many images - that would prevent us from fetching other, more important data from the Twitter API. Am I overlooking documentation? If not would you mind updating the existing documentation to include this information?

In general it’s hard for me to understand why there’s such a strict limitation at all. I can understand you put the images behind an authorization wall due to security reasons. But why limit how many pictures can be requested while authenticated VS the non-existing limit (or extremely high limits) for non-authenticated images? – Was this just an unintended side-effect of adding authentication? Any chance you’ll be able to elevate or remove these limits?

Best regards


We do not publicly document our rate limit for DM images, but you should be able to handle all of your images by implementing an image cache system.

This shouldn’t be an issue, as our rate limits are per endpoint, which you can find in their respective API reference pages.

If you truly can’t address your rate limit issue by caching, we do have an elevation pathway, but you should try to build a more efficient system before we go that route.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.