Just a reminder: today was the day for this change to go live, and it
just went live.
On Thu, Dec 4, 2008 at 12:42, Brooks Bennett [EMAIL PROTECTED] wrote:
I agree, this is a great change.
On Dec 3, 11:07 pm, dean.j.robinson [EMAIL PROTECTED]
wrote:
return the representation of the
Thanks Alex, looks great.
I'm playing with it now and am looking to use it to replace the
additional show/user.json call that I previously needed. There are a
few properties that are in user/show but not in the verify_credentials
method, I was wondering if there are plans to include these in a
It does return an error (along with the header) as well. Thanks for
adding the user data to this call. Saves an extra call for our
service.
--
Swap
On Dec 11, 7:07 am, Alex Payne [EMAIL PROTECTED] wrote:
Just a reminder: today was the day for this change to go live, and it
just went live.
that would be brilliant, it would allow me to completely eliminate the
additional api call I'm using, while making sure I can still keep
users profile settings up to date on each login.
no rush though, thanks in advance :)
On Dec 11, 2:34 pm, Alex Payne [EMAIL PROTECTED] wrote:
I can have it
I agree, this is a great change.
On Dec 3, 11:07 pm, dean.j.robinson [EMAIL PROTECTED]
wrote:
return the representation of the authenticated user
does that mean that the response will be the same as if we
calledhttp://twitter.com/users/show/id.format for the authenticated user?
If so that
return the representation of the authenticated user
does that mean that the response will be the same as if we called
http://twitter.com/users/show/id.format for the authenticated user?
If so that would be awesome and means I could completely eliminate
some of the extra api calls that I'm
As per http://code.google.com/p/twitter-api/issues/detail?id=173 we'll
be changing the /account/verify_credentials method to return the
representation of the authenticated user. Because some applications
depend on the contents of this response, we're delaying this change
until December 10th,
