I don't mean that, strictly, no. Most Twitter API calls have the concept of
a "current user" -- in basic auth, that concept of a "current user" was
indicated by a valid username and password associated with each API call.
Our most employed authorization form at this time is OAuth 1.0a, which
exchanges the user's express permission for you to act on their behalf for
an access token that represents that permission. It's this access token that
would accompany requests made on a user's behalf, and
ultimately represent the user in the same way a login and password did in
the past.

Taylor

On Mon, Oct 4, 2010 at 10:55 AM, Theswalker <blue98cam...@gmail.com> wrote:

> When you say "if your API calls are
> executed from the perspective of a member (represented by an access
> token)" Do you mean require the user to pass username and password
> credentials to get updates?
>
> On Oct 4, 1:05 pm, Taylor Singletary <taylorsinglet...@twitter.com>
> wrote:
> > There are many options with the Twitter API today. There are a number of
> > streaming-based products, like the core Streaming API, User Streams, and
> > Site Streams. Streaming technologies give developers alternate
> > implementation paths to monitor tweets of certain users, certain keyword
> > searches, and numerous other use cases.
> >
> > By using Streaming in conjunction with the REST API, the vast majority of
> > developers should never require whitelisting. Further, if your API calls
> are
> > executed from the perspective of a member (represented by an access
> token),
> > you'll have 350 requests per hour/user for supplemental API requests.
> >
> > If your application requires more API calls than this to continue
> > functioning, you may need to explore other implementation options, such
> as
> > streaming APIs, even more aggressive caching, or more complex request
> > queueing systems. Have a user that needs more than 350 requests in an
> hour
> > to completely process for some operation in your application? Queue the
> rest
> > of your operations for later. You essentially have 8,400 requests per day
> to
> > make requests on behalf of a user.
> >
> > Taylor
> >
> >
> >
> > On Mon, Oct 4, 2010 at 9:50 AM, Theswalker <blue98cam...@gmail.com>
> wrote:
> > > I was rejected just now and i'm not sure why really. I read the link
> > > they sent me and i comply with all of the requests. I have a caching
> > > server that updates users latest tweets that puts that information in
> > > a database. When someone visits a users profile page, i return the
> > > cached results instead of updating on page loads. My site has over 200
> > > users right now and i hit the limit every time my server updates the
> > > cache and i dont know what to do now. It's pointless for me to even
> > > have twitter as an option on my site if it wont allow my site to grow
> > > past 150 users. Can anyone help me or give me any pointers on how to
> > > get whitelisted? The link says to do the following:
> >
> > > 1. Caching - which i do already.
> >
> > > I update a users stream once every 30 minutes and store that
> > > information in my caching server.
> >
> > > 2. Rate limiting by active user. If your site keeps track of many
> > > Twitter users (for example, fetching their current status or
> > > statistics about their Twitter usage), please consider only requesting
> > > data for users who have recently signed in to your site.
> >
> > > The point of my site is to allow users to link different social
> > > networks on their profile and send it around to friends and not have
> > > to login to get it to update.
> >
> > > Any help will be appreciated.
> >
> > > Thanks
> >
> > > --
> > > Twitter developer documentation and resources:
> http://dev.twitter.com/doc
> > > API updates via Twitter:http://twitter.com/twitterapi
> > > Issues/Enhancements Tracker:
> > >http://code.google.com/p/twitter-api/issues/list
> > > Change your membership to this group:
> > >http://groups.google.com/group/twitter-development-talk
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to