Discussing API v1.1

tincloud · 2013-03-07T07:57:15.000Z

I have a similar problem trying to tweet the british pound sign character, which used to work fine with the old API.

andy_wickes · 2013-03-08T13:23:00.000Z

When creating an app, I noticed that on the OAuth tab there is a field that was automatically populated with the Request URL.

This had the address of https://api.twitter.com/1/

The only reason I was doing this was because we wanted to move to API 1.1 in the light of recent news.

Is https://api.twitter.com/1/ correct? I can change the address but there is no button to SAVE settings so when I move off that tab and come back again my changes haven’t been saved.

A

episod · 2013-03-08T15:01:43.000Z

It’s just offering you a template to suggest how to use the tool. We’ll make sure that suggestion gets updated to point to 1.1.

potasmic · 2013-03-11T11:14:00.000Z

I am not a developer but a Twitter user. I have lots of friends so I refresh my timeline once or more per minute. I am using a unofficial Twitter client, they just switched to API 1.1. Now, I usually get this message “Twitter usage limit reached”, I still can tweet though. Everything this happens I have to use the official app to continue tweeting, does this related to the new API?

eartothenoise · 2013-03-11T21:41:59.000Z

Why is /lists/statuses not returning native RTs even with include_rts=1?

episod · 2013-03-11T21:46:49.000Z

In case you missed it, we released [node:15742, title=“application-only auth”] today.

en_Pintalabios · 2013-03-12T16:17:00.000Z

Hello i got this error “”" is over daily photo limit",“code”:191 “”" uploading media to https://api.twitter.com/1.1/statuses/update_with_media.json How can i get the limits before this happens again? I liked to know limits of media , and time waiting before i can upload media again.

In this link https://dev.twitter.com/docs/api/1.1/post/statuses/update_with_media says
Rate Limited? No What does that mean? Thanks

episod · 2013-03-13T14:25:46.000Z

Write limits on Twitter are handled differently than rate limits – they aren’t programmatically disclosed. There is a daily limit of 1000 tweets per day, divided into roaming windows of time. Of those 1000 tweets, only a certain amount can be pic.twitter.com uploads.

episod · 2013-03-13T14:26:41.000Z

I’m not able to reproduce. You may find that recently created lists or lists with recently added members don’t immediately contain recent retweets as the virtual timeline is assembled though.

TigMH · 2013-03-14T00:20:21.000Z

The recent changes seem to work fine if you are wanting to create a timeline widget for yourself or a specific user or search, etc…

However, what if you don’t want to (or are unable to) create a separate widget for each user or search phrase you wish to see timeline on? Understanding what your clients/prospects are tweeting is valuable information, especially when embedded into a CRM application, such as Salesforce.com. What if you simply want a widget that:

Provides a read only timeline (preferably streaming) about a public user or search term.
Allows for the user or search phrase parameter to be defined by information on the page the widget is displayed on (such as a field that contains the Twitter User Name)
Doesn’t require your users to login to Twitter (many don’t have Twitter accounts, they simply want to view a twitter feed where it will be most relevant to them, e.g. on an account, contact, lead, or other object/record in a CRM)

There seems to be a lot of confusion and questions regarding the recent API changes, and most of the documentation and information available seems very directed at individuals or businesses that want to embed their twitter feed on their website or blog. The scenario described above is a very simple but common business need that seems to have been overlooked (or lacks documentation).

Any insights on how to handle this situation would be greatly appreciated.

episod · 2013-03-14T14:46:57.000Z

Right now, if someone were to want to have a widget with all of those specific features they’d have to build it themselves. [node:13439] is useful for not having to require an end-user login. We get a lot of feedback that developers want more flexibility with Embedded Timelines, and we’re definitely receptive to that feedback.

shags78us · 2013-03-15T04:48:40.000Z

There is a difference between API1 and API 1.1 in the URL encoding for UTF-8 beyond ASCII…Is this now encoded differently, ie not twice anymore? Some example strings and the encoded strings, please.

episod · 2013-03-15T14:17:58.000Z

API v1.1 is stricter in to primary ways – first it requires that valid HTTP 1.1 (including the sub-specifications on URLs and POST bodies) be followed virtually to the letter. OAuth 1.0A’s signature base string has its own specification for how strings should be encoded, and we now follow that strictly as well. Often an encoding issue in OAuth is actually due to a mis-encoding on the URL or POST body level.

Are there specific strings you’re having trouble with?

shags78us · 2013-03-16T19:58:50.000Z

No problem with Oauth. But the non-ASCII strings (non-English language character string) in the tweet body, that were working well under API 1.0 not not working under API 1.1. SO for a different language string in the body of the tweet, can you point to examples.

step3profit · 2013-03-20T16:09:46.000Z

I am hoping the blackout today (3/20/2013) does not affect me, because I am still using basic auth, but on the 1.1 streaming API. Can anyone confirm/deny?

episod · 2013-03-20T16:49:04.000Z

The blackout test today applies only to the REST API v1. Please do migrate to OAuth on stream.twitter.com soon though.

step3profit · 2013-03-20T16:51:27.000Z

Yep, this just scared us into action. Thanks for verifying!

michrhead · 2013-03-21T16:54:26.000Z

Title: Social Graph Information (The first post in this thread)

The limited use of followers/ids and friends/ids is a HOT issue under 1.1, and many suggest increasing the limit of this endpoint. I’m not convinced with that because instead of GETing ALL followers/friends ids, app could GET ids changed since a previous fetch of ALL ids.

Considerations: Twitter does need to control server hits, and users need info for social graphing functions etc. One may think that getting followers/friends counts is the same thing. By getting IDs, an app knows who* their community is, e.g. how long ago a user followed, which users followed in the month/week/day/hour of. Much more useful value than simple counts. This feature is critical.

Goal: A solution that satisfies requirements for both Twitter and users that is not a workaround.

What does Twitter require?
To reduce bandwidth costs all around
Allow Twitter Eco-system to scale even better

What do users/devs actually require for the issue tho?
(1) Two pieces of info…

(a) followers-since/ids. New followers SINCE a previous point (cursor or last time based)
(b) lost-followers-since/ids. New lost followers SINCE a previous point (cursor or last time based)
(2) To reduce bandwidth costs all around
(3) Allow app to scale even better

Both parties share requirements, once an app caches it never need cache again with the two endpoint suggestions (1).

Use case example… an initialized cache contains… id_str 1, id_str 2, id_str 3

GET new endpoint (1-a) returns (id_str 4, id_str 5) … app can add (id_str 4, id_str 5) to cache

GET new endpoint (1-b) returns (id_str 2, id_str 3) … app can purge (id_str 2, id_str 3) from cache

result
app cache contains… id_str 1, id_str 4, and id_str 5
app knows how many ids there are with no further API hits to original endpoints used to create cache

– Outcome of this proposal –
Bandwidth costs are significantly reduced for Twitter, devs and users.

App becomes far faster to sync than now, plus is synced tighter to Twitter.

Social graphing suddenly becomes very cheap. Why? Very few accounts get more than 75,000 new followers a DAY, and even less lose 75,000 followers. Very few API hits are required, a result correct?

The initial scan may take the 1.1 rate limit * hours/days to cache, but from then on, very few calls are required to keep updated. Compare that with API 1.0 where many GETs are needed in order to sync. This proposal would also deprecate a lot of social graph sync code from any existing app, a bonus for devs.

Twitter servers would be stress relieved and devs 99% happy; the initial sync time being a minor bug bear.

Please Twitter consider this a high priority feature to implement before API 1.0 is permanently deprecated. What do you think @episod, can you make it so?

neconeco64 · 2013-03-21T07:22:57.000Z

there is a demand for the “/application/rate_limit_status”. Some of the information that this API will come back, but I’d like you to include the information in the “/statuses/ update_status_with_media”, Is it possible?

episod · 2013-03-21T14:44:58.000Z

Perhaps some day. But at this time we don’t consider writes “rate limited” and therefore it’s not appropriate for their “allowances” to be expressed through the rate limit method. The daily limits are also often broken into roaming windows of time, with intentionally undisclosed duration and amounts allocated.