New Direct Message API Delayed

[Sam_Ruston]

There seems to be a delay between sending a message (direct_messages/events/new) and when that message shows up (direct_messages/events/list). This is consistent (seems to be about a 2-3 minute delay) and is reproducible using the example Twurl requests given in the docs. Is this intentional or a bug?

Thank you for any help or insight you can provide.

[Sam_Ruston]

As an update, I have tested it using Twitter.com. Sending a message using the API updates Twitter.com instantly, but sending a message from Twitter.com still takes a few minutes to update the API.

[Sam_Ruston]

Any updates?

[andypiper]

Hey Sam, sorry for the pause on this one, I had to do some checking!

There are two ways to work with the new Direct Message API - realtime, and via REST, which is effectively for data synchronisation. The Account Activity API offers webhooks for Direct Message events in realtime. The REST API complements it to bootstrap recent conversation history and synchronise data, but as you’ve found, it is not as immediately responsive as the Account Activity API.

I realise you’re (very likely ) asking in an end-user client app scenario, and the webhooks option is less attractive than the direct REST access - however, that’s the way these two methods have been designed to operate. Thanks for the excellent question.

[Sam_Ruston]

Thanks for the response. I haven’t had the chance to try the webhooks API yet, but does it send events when they happen or when they are added to the REST version?. I’m assuming it is the former as otherwise it wouldn’t be very real-time, but that leads to a problem if the webhook only sends events for events that have occurred after the subscription. For example if someone sends me a DM a minute ago and I get the current state of the DM using REST (which wouldn’t include it) and then register a webhook subscription then I would never get the missing DM. Does the webhook API compensate for this in some way?