> I am getting a discrepancy with regards to the currently logged in user.
> When I do a OAuth fetch I get the user id as

>     "identity": {
>         "email_address": "x...@xxx.xxx",

>         "first_name": "Arif",
>         "id": *3495765*,
>         "last_name": "Amirani"

>     }

> Whereas when I fetch my todos I get the ID as something else:

>         "assignee": {
>                     "id": *26385*,

>                     "name": "Arif Amirani",
>                     "type": "Person"
>                 },

> On login how do I get the todo user id?

> On Thu, Oct 18, 2012 at 6:57 AM, Arif Amirani <arif.a...@gmail.com<javascript:>
> > wrote:

>> Hi folks,

>> I am getting a discrepancy with regards to the currently logged in user.
>> When I do a OAuth fetch I get the user id as

>>     "identity": {
>>         "email_address": "x...@xxx.xxx",

>>         "first_name": "Arif",
>>         "id": *3495765*,
>>         "last_name": "Amirani"

>>     }

>> Whereas when I fetch my todos I get the ID as something else:

>>         "assignee": {
>>                     "id": *26385*,

>>                     "name": "Arif Amirani",
>>                     "type": "Person"
>>                 },

>> On login how do I get the todo user id?

> Hi Arif -

> This is, confusingly, exposing some of the internals of our data model.
> There are actually three ids at play here: the Identity, the User, and the
> Person.

> The Identity is the id in your OAuth fetch. The User is a record that that
> Identity is on this Account. And the Person is the actual Basecamp user.
> That's the assignee id you listed.

> So you can't directly correlate a Person id with an Identity id. However!
> You can `GET /people/me.json` to get info about the currently authorized
> Person and link that info to the Identity.

> To make this a bit clearer, we've added identity_id to the Person JSON so
> you can directly correlate Basecamp people with 37signals IDs.

> --
> Jeremy Kemper
> 37signals

> On Fri, Oct 19, 2012 at 3:51 AM, Arif Amirani <arif.a...@gmail.com<javascript:>
> > wrote:

>> In my application, being on mobile, I would like to optimize on the
>> number of HTTP calls that are made to fetch data. Given that an OAuth is
>> mandatory, it should contain the "me" information in the response to make
>> the "me" API call optional.

> That would be convenient. However, the OAuth service is completely
> separate from the applications it authorizes access to, so that information
> is not available.

>  Making a "who am I?" request after you've authorized the app is a
> one-time cost. I'd suggest focusing your HTTP optimization efforts on your
> main API usage. Supporting HTTP cache freshness headers often has the
> biggest bang for the buck: track ETags in API responses, make subsequent
> requests with If-None-Match, and handle 304 Not Modified responses.

> --
> Jeremy Kemper
> 37signals