I’m sure you’ve read @jasoncosta’s [node:10635, title=“blog post”] announcing the new version of the API. This thread is to collect a few loose ends, upcoming improvements, and known errata.
- Look for the blue pills that will indicate what version of content you’re looking at. [version:1.1]
- Check out the [node:10639] for a high-level summary on what’s changed.
- The entire 1.1 API requires a user context when authenticating at this time with OAuth 1.0A. That means an oauth_token representing an access token must be present in each request. In the near future we’ll have an additional form of authentication for a “userless” or application-only context for many methods.
- Write operations are considered the same way as they’ve always been in API version 1.0. Accounts have specific allowances for tweeting and sending direct messages and so on and those are still intrinsic to the account and handled similarily. In the near future we’ll have the same per-method rate limiter also handle write operations, allowing for more dynamic & generous limiting on content creation and modification.
- While the majority of 1.1’s documentation is present, you’ll find us continuing to update much of the documentation throughout the next few weeks. Report any documentation errors you find for API v1.1 [alias:/issues, title=“here”] or in this thread.
- If you’ve been experiencing rate limiting on widgets at your corporate office or other shared network, you’ll definitely want to check out our [node:10248, title=“new embedded timelines”].
- API v1.1 has a concept that hasn’t been well-documented yet: “user entities” – these are primarily to identify and resolve t.co links in user objects. For most developers experienced with entities, the meaning of these fields should be clear. Expect explicit documentation on this soon.
- Some methods may still support a “per_page” parameter when “count” is the parameter we intend. These are few and far between and will be rectified in the coming weeks.
- Occasionally you may see a documentation page that claims it may represent deprecated information. Unless it’s a 1.0 resource method, consider it a warning and use your own judgement on whether the documentation represents a conflict with the version 1.1 world.
- Let us know if you see any issues with error response conditions – whether they occur unexpectedly, if the response format is not in JSON, or if the status line and payload is unclear. We’ll be improving the [node:130] documentation to include more information on the better-structured errors you’ll be encountering in 1.1.
- You may find it difficult to properly tweet with /1.1/statuses/update_with_media at the moment (UPDATE: this has been resolved, use https://api.twitter.com/1.1/statuses/update_with_media.json for this operation)
- The Search API in 1.1 makes a few references to its deprecated page parameter. It also may occasionally be missing user objects. Fixes forthcoming. (UPDATE: 1.1 Search now has proper retweeted_status objects, user objects, and an improved search_metadata – see [node:513]
- We’re still updating our [alias:/docs/faq, hash=“rest-api-v11”, title=“API v1.1 FAQ”]. Please keep the questions coming!
The entire platform relations team is excited to work with you on API v1.1, the first major upgrade the API has seen in some time.