DM Image proxy & rate limiting

[patrickd_de]

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.

Direct Message API - Change to how apps can access images sent in Direct Messages

As part of our continuing efforts to strengthen the security of our systems, today we implemented a change to how apps can access images sent in Direct Messages through our API. Due to the potential sensitivity of the prior state, we were unable to provide advance public notice of this change. If your products or services are integrated with Twitter’s Direct Message API and render images sent via Direct Messages, please see below for the details of the change and determine whether you need to m…

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.

Rate limiting when getting DM images

Hi, we are being rate limited when getting images using auth on DM messages. We download them to our own server so our customers can answer properly and see media. But the limit it’s too low for corporate usage. We are using the paid API, can you guys increase the rate limit for paid accounts? This is becoming a critical issue for our customers because they can’t see private media. Regarding this post Direct Message API - Change to how apps can access images sent in Direct Messages In the d…

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

[LeBraat]

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.

[patrickd_de]

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

[LeBraat]

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.

that would prevent us from fetching other, more important data from the Twitter API

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.

[system]

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