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 Team
http://twitter.com/raffi

Reply via email to