That's exactly what I was wondering, helps for planning. Thanks Raffi!
On Dec 14, 11:14 pm, Raffi Krikorian <ra...@twitter.com> wrote: > what we have not yet exposed is the "invitation" or "linking step" - but, > you are mostly correct. to carry on with my example, @twitter would > "invite" @raffi to contribute on its behalf. now @raffi, has the ability to > call API endpoints with contributingto=783214. �...@raffi and @twitter are > both > twitter accounts, but @twitter has enabled itself for contributors to access > it. > > does that help? > > > > On Mon, Dec 14, 2009 at 8:33 PM, Justyn <justyn.how...@gmail.com> wrote: > > Hi Raffi, > > > Curious how the contributors will be associated? Will it essentially > > be linking accounts? Presumably then the user would identify in an app > > which account to post an update to based on those accounts they have > > been associated as contributors to? So, a "contribution" would > > originate from a separate Twitter account, let's say @Raffi and be > > posted to @Twitter. The primary difference from what we're used to > > with CoTweet for example, where you may have many authors with no > > individual twitter accounts, this would all be based on having two or > > more accounts (1 biz account linked to contributor accounts). Does > > that make sense? > > > Justyn > > > On Dec 14, 6:07 pm, Raffi Krikorian <ra...@twitter.com> wrote: > > > As you may have seen on our > > > blog<http://blog.twitter.com/2009/12/feature-test-with-businesses.html>, > > > we're starting a very small test of a new feature that will allow a > > Twitter > > > account to have multiple "contributors". This is the first in a suite of > > > features that we'll be rolling out specifically targeted to the needs of > > > businesses, and this particular feature is going to allow a business to > > > invite employees and representatives to tweet, DM, follow users, etc., on > > > behalf of the account holder. > > > > While this feature is not ready for prime-time, and while we're not yet > > > taking requests to be part of an early-access release while we work out > > the > > > kinks, we're really committed to keeping our developers in the loop. I > > want > > > to give you all a heads up on what is coming on the API side, and, for > > this > > > particular feature, I wanted to give you all a look at what we're calling > > > the "Contributor API". The reason I want to really highlight these > > changes > > > is because we'll be making an addition to the status objects as this > > rolls > > > out. > > > > We'll be introducing a new parameter called contributingto to most API > > > endpoints -- this parameter must be set to the user ID of the user that > > the > > > employee or representative wants to take the action on behalf of. If > > using > > > contributingto, then the caller must authenticate when calling and must > > use > > > OAuth. For example, if I, @raffi, wanted to tweet on behalf of @twitter > > (ID > > > 783214), I would call /status/update.xml, I would attach a parameter of > > > contributingto=783214, and I would authenticate to that endpoint as > > myself > > > using OAuth. The API will confirm that @raffi has permission to > > contribute > > > to the @twitter account, and will error with a 403 if that account does > > not. > > > > You can expect to see contributingto show up as an optional parameter to > > the > > > following endpoints (and presumably some more) when calling onhttp:// > > api.twitter.com/1: > > > > /account/rate_limit_status > > > /account/update_profile > > > /account/update_profile_background_image > > > /account/update_profile_colors > > > /account/update_profile_image > > > /account/verify_credentials > > > /blocks/blocking > > > /blocks/blocking/ids > > > /blocks/create > > > /blocks/destroy > > > /blocks/exists > > > /direct_messages > > > /direct_messages/destroy > > > /direct_messages/new > > > /direct_messages/sent > > > /favorites > > > /favorites/create > > > /favorites/destroy > > > /followers/ids > > > /friends/ids > > > /friendships/create > > > /friendships/destroy > > > /friendships/exists > > > /report_spam > > > /saved_searches > > > /saved_searches/create > > > /saved_searches/destroy > > > /saved_searches/show > > > /statuses/destroy > > > /statuses/followers > > > /statuses/friends > > > /statuses/friends_timeline > > > /statuses/home_timeline > > > /statuses/mentions > > > /statuses/public_timeline > > > /statuses/retweet > > > /statuses/retweeted_by_me > > > /statuses/retweeted_to_me > > > /statuses/retweets > > > /statuses/retweets_of_me > > > /statuses/show > > > /statuses/update > > > /statuses/user_timeline > > > /users/show > > > > Lastly, the <status> objects will include an additional parameter named > > > contributors that will have an user_id with the ID of the user who > > actually > > > created this status object. An example XML status would have > > > > <status> > > > ... > > > <contributors> > > > <user_id>ID of the contributor</user_id> > > > </contributors> > > > ... > > > </status> > > > > and in JSON > > > > { > > > ... > > > "contributors" : [ID of the contributor], > > > ... > > > > } > > > > Due to caching, historical status objects may or may not contain the > > > contributors, but all status created after launch will. > > > > Like I said, more details to come! > > > > -- > > > Raffi Krikorian > > > Twitter Platform Teamhttp://twitter.com/raffi > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi
