TripIt Notification Endpoint Possibly Not Seen Called

[Skydaddle]

Hi,

I successfully completed the 3-legged OAuth with TripIt to authorize my App to access TripIt itinerary information. I also was successful registering for trip notifications. However, when sending an itinerary to TripIt I did not detect, subsequently, my registered endpoint being called. Could someone check and report if an error was thrown?

Also, as I mentioned before, I worked my way through the OAuth process. From what I can tell, this allows my TripIt App access to a user trip items. What I'm not clear about is how TripIt can notify my endpoint of a trip update/change w/out having to go through the same type of OAuth process.

Clearly I am missing something about this process, but if someone could shed some light on how TripIt can gain access to my endpoint w/authorized credentials I would appreciate it.

Finally, (sorry one more) our registered notification endpoint for our TripIt App varies depending on where our software is installed. In other words, the callback would be the same except for the base url. How can our TripIt App be created such that it can callback to a different endpoint depending on which subscriber to our service authorized the app? Is there a way to dynamically register a notification endpoint?

Thanks again and Best Regards,

Tom tom@skydaddle.com

[garyhooper]

I'm using Firebase to store my users' data, but any environment should be the same conceptually.

Each Firebase user has his private data, including the TripIt OAuth key info, and therefore direct access to his trips. (The user went through OAuth once, and saves all key info in his profile.) In Firebase I also have a "public" (public to all app users, not the world) area where I store all notifications, including who is being notified about what, and whether the notification has been processed by the user.

Each user watches his notification area. When the TripIt notification system notifies my endpoint (a Node.js server also using Firebase), it in turn creates a new entry in the "public"/notifications/user. Since the user is watching this area, he sees this notification directed at him, which he then processes.

Hope this helps...

[hliss]

I'll add here a couple little extras that might cause some counterintuitive behavior.

First, if you make a write request (create/replace) to a user's account via your API client, your API client will not get a notification. We assume that you already know about the change, since you made it.

Secondly, notifications for a trip will be collapsed within a 10 minute window. The first one will always be sent, and then we will collapse any future rapid-fire changes in the next 10 minutes into one notification. See http://tripit.github.io/api/doc/v1/notification.html for more information on that. Notifications are sent with an oauth_token_key parameter; this is the same token used to identify a user of your application.

To answer the other question, multiple callback URLs are not supported per user. Per environment (i.e., development vs production), you can use different API consumers with different URLs registered. One way to differentiate per user is to create an intermediate single endpoint that would know how to route a user's notification to the correct endpoint.

[Skydaddle]

Hi Gary,

Thanks for the response. I will certainly look into Firebase. However, I'm not sure if that is suited to the environment that I'm working in. Thanks for the suggestion!

Hi Harold,

Our service is just listening for trip change notifications. In other words, we would not be making trip changes via the API. I've read the documentation and understand the collapsing of notifications. Make sense.

It doesn't seem like callbacks are on a per-user level in the first place. The callback was registered with the TripIt app and not the user who authorized the TripIt app. The use-case that I have is to create a single TripIt app that many users from different organizations can authorize access to their trip change notifications but be called at different endpoints depending on which organization has installed our service (e.g. the callback endpoint base url will vary).

Best Regards,

Tom

[hliss]

Apologies, @Skydaddle, but there's no such support for more than one callback URL per application.

[Skydaddle]

No worries Harold. Again, thanks for your help in shedding more light on the TripIt App workflow. Feel free to close this issue.

Best Regards,

Tom